Age | Commit message (Collapse) | Author | Files | Lines |
|
This uses a similar approach to Gtk, where surfaces are created every draw
call. It is a bit slower for a single application in most cases, but uses less
memory when drawing isn't happening and plays more nicely with other views or
applications.
|
|
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.
|
|
Cairo has a built-in cache that makes this fast enough to not matter, and it
removes some state which is always good.
|
|
|
|
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 was the only use of actual GL in the backend, and I'm relatively sure this
flush is pointless anyway. If, for some bizarre reason, anyone really wants to
run without double buffers, they are always free to flush themselves.
|
|
|
|
|
|
|
|
This establishes a general pattern for backend-specific APIs, so that pugl.h
doesn't become a mess. The name of these headers, and the definition of
"backend", is a little fuzzy here, but it was before in reality anyway.
|
|
|
|
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.
|
|
This doesn't change anything about type-safety (C can't do that), but at least
makes the intent of things clearer.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
This was just leftover cruft from before error handling was cleaned up, any
failure to configure must now be reported by the backend.
|
|
|
|
This allows backends which use basic software rendering (like Cairo) to share
the common basic window format setup code.
|
|
Towards having actual trivial backends, but in general allows backends to not
declare functions they don't care about which is nice and already a net
reduction of actual code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows projects that use strict warning flags to suppress warning noise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prepares the API for proper error handling, even though there isn't any for
these functions yet.
|
|
Currently unused, but this is to leave open the possibility of event
propagation or better errror handling.
|