The primary goal here was to cleanup the current GL renderer to make
maintenance easier going forward. Furthermore, it tracks state to allow
us to implement more advanced renderer features going forward.
Reordering
This renderer will reorder batches by render target to reduce the number
of times render targets are changed.
In the future, we could also reorder by program within the render target
if we can determine that vertices do not overlap.
Uniform Snapshots
To allow for reordering of batches all uniforms need to be tracked for
the programs. This allows us to create the full uniform state when the
batch has been moved into a new position.
Some care was taken as it can be performance sensitive.
Attachment Snapshots
Similar to uniform snapshots, we need to know all of the texture
attachments so that we can rebind them when necessary.
Render Jobs
To help isolate the process of creating GL commands from the renderer
abstraction a render job abstraction was added. This could be extended
in the future if we decided to do tiling.
Command Queue
Render jobs create batches using the command queue. The command queue
will snapshot uniform and attachment state so that it can reorder
batches right before executing them.
Currently, the only reordering done is to ensure that we only visit
each render target once. We could extend this by tracking vertices,
attachments, and others.
This code currently uses an inline array helper to reduce overhead
from GArray which was showing up on profiles. It could be changed to
use GdkArray without too much work, but had roughly double the
instructions. Cycle counts have not yet been determined.
GLSL Programs
This was simplified to use XMACROS so that we can just extend one file
(gskglprograms.defs) instead of multiple places. The programs are added
as fields in the driver for easy access.
Driver
The driver manages textures, render targets, access to atlases,
programs, and more. There is one driver per display, by using the
shared GL context.
Some work could be done here to batch uploads so that we make fewer
calls to upload when sending icon theme data to the GPU. We'd need
to keep a copy of the atlas data for such purposes.
Don't warn about Compose file constructs we don't
support. We haven't supported these for a long time,
and nobody has every complained. No need to wake
up sleeping dogs.
Tweak the preedit text we get from IBus (via the compositor) to
match what GtkIMContextSimple produces for Compose sequences now.
This provides a unified experience.
Tweak the preedit display for Compose sequences to
be not so distracting. We only show the Compose key
when it occurs in the middle of the sequence or is
the only key so far, and use · instead of ⎄ for it.
Also, make sure to display dead keys more adequately.
In some cases, we were inadvertedly merging the
preedit attributes into priv->attrs, instead of
keeping them separate. This was causing the underlines
to grow beyond the preedit and never go away. One
place where this was showing up is the fontchooser
preview.
Fixes: #3679
Instead of bending GtkGizmo to the breaking point,
split off a GtkPanedHandle class that just does
what is needed here. Its simpler, and lets us keep
GtkGizmo simpler too. Everybody wins.
Instead of bending GtkGizmo to the breaking point,
split off a GtkPopoverContent class that just does
what is needed here. Its simpler, and lets us keep
GtkGizmo simpler too.
- window resizing control area is implemented as where the shadows are drawn
- create a 'fake' shadow for the tiled case to allow easier resizing of
the tiled window ratio even if it's offset to the side of the border
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3670
css_changed is a vfunc that *must* chain up.
Failure to do so broke the resizing of overlay scrollbars,
amongst other things.
This bug was introduced in 39f72b3834.
X11 allows keysyms to be specified in addition to strings.
We only support the strings. In the past, we ignored everything
after the string. Go back to doing that, but issue a warning
that we've ignored the keysym.
Use gdk_popup_layout_set_shadow_width to take shadows into
account when positioning popovers, and set the input region
to exclude the shadow, since we aren't doing interactive
resizing and the like.
When the popover has a beak, we make the surface size be
content size + shadow + tail, and then position the content
according to the final position inside this slightly too large
surface. The surface being too large doesn't matter, since we
set up an input region.
The places view has questionable code for handling
'destroy', which seems to trigger use-after-free in
some cases. Clean this up a bit by acknowledging the
cancellation fully, rather than relying on the
destroyed flag.
- while the case of a single half tiled window casting shadow is valid,
the main use case for half tiled windows is when they have a neighbor.
The :backdrop should be enough of a focus indicator and we avoid shadow
casting on neighbors that are on the same Z level.
These shadows cause a significant draw performance drop for maximized
windows. Disabling them increases the chances we can have faster scroll
performance of text.
There is some risk here for systems where they have a dock and you expect
the shadow to draw beneath that dock for transparency reasons.
