| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
It does not seem to be guaranteed that child windows receive a ConfigureNotify
at all. Work around this by explicitly dispatching one first, so child views
receive events consistently with how top level views do.
|
|
The updates here need to happen whenever a configure is dispatched, even
outside puglDispatchEvent(). This removes the last remaining direct calls to
the event callback so the common implementation can always do the right thing.
|
|
|
|
The previous separation between polling and dispatching was a lie, especially
on MacOS where it is impossible to only poll for events without dispatching
anything. Providing such an API is misleading, and problematic in various
other ways.
So, merge them into a single puglUpdate() function which can do the right thing
on all platforms. This also adds the behaviour of actually processing all
events in the given time interval, which is almost always what clients actually
want to do when using a positive timeout (naively doing this before caused
terrible input lag).
|
|
|
|
Unfortunately this is an API break, but there's no reasonable way to deprecate
the old function and this is required for things to work correctly. The type
will be used in following commits to tick the main loop and dispatch events
correctly for either case.
|
|
|
|
|
|
|
|
These continue statements are not necessary since the events will not be
translated anyway.
|
|
This reduces input lag. The previous approach was an over-optimization: what's
important here is to keep the iteration bounded by not continually flushing,
but we do want to read everything to be as up to date as possible.
|
|
|
|
This fixes some jittery display issues since the frame can be used before the
deferred configure actually gets dispatched.
|
|
|
|
|
|
|
|
|
|
|
|
This event makes it possible to send an arbitrary event to a view, which is
useful for many things. In particular, this method of communication with views
will wake up the event loop, unlike hacks in applications that share data in
some other way.
|
|
|
|
|
|
These can be used to do things when a view is created or destroyed, in
particular set up the GL context in a more controlled way. Map and unmap
events are also added for when views are shown and hidden so application can
react to this as well.
Towards the deprecation of puglEnterContext() and puglLeaveContext(), which are
prone to abuse.
squash! Remove client event stuff
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is needed for clipping. Unfortunately, the puglEnterContext() and
puglLeaveContext() API was not suitable for this, but this shouldn't matter in
user code because it is only used for setup, and is slated for removal anyway.
Instead, just call the backend functions directly in the implementation.
|
|
This was a hack to support only exposing the rects that were explicitly exposed
with puglPostRedisplayRect(), but it caused flaky drawing issues because it
circumvented the deferral of exposure until the end of the loop. Instead,
simply expand the pending expose to be dispatched later as usual.
This means that only the union will be exposed in the end, so more area might
be drawn than necessary, but this is probably good enough. If not, we will
have to maintain a set of rects and be more clever about combining them.
|
|
|
|
In Xlib, a return value of 0 indicates an error (see "Xlib - C Language X
Interface", Ch. 1, "Errors"). XMoveResizeWindow accordingly returns 1 on
success, but the error check in puglSetFrame used the usual C convention, and
so was backwards.
|
|
This avoids resizing the backend when the window is only moved, which fixes
flicker with Cairo where resizing is expensive.
|
|
|
|
|
|
|
|
Working on Vulkan clarified what has always been slightly smelly about the
design and organization here: not everything that is API specific is really in
a "backend" (a PuglBackend). The concrete example is puglGetProcAddress(),
which only makes sense for GL and is actually implemented in the "backend"
files. Arguably puglGetContext() is also such a thing.
So, rename the headers so they can be the place where API-specific things go in
general, which happens to include a backend most of the time. The stub is a
bit of an exception to this, but whatever. The includes look tidier this way.
In place of the old headers are compatibility stubs that just emit a warning
and include the new version, which will be maintained for a while.
|
|
|
|
|
|
This is a bit ridiculous, but using a "probably big enough" value seems to be
what everyone does. This particular value is the one used by Gtk.
|
|
|
|
This ensure that visibility is properly updated when a window is made visible
or invisible by the user or window system. Unfortunately it does not seem to
propagate automatically to child windows, but this is at least better than the
previous situation, and good enough for most cases.
|
|
|
|
|
|
Towards actual fine-grained exposure. This uses the previous behaviour if
expose events intersect to reduce redundant drawing, but dispatches expose
events immediately (after flushing and pending configure events) if they don't
to support partial redraws.
|
|
|
|
|
|
|
|
|
|
|
