This was showing up quite high on the profiles, and there is
no real reason for copy to normalize, as the source is a
GskRoundedRect which should be normalized already unless
you did something very strange (and then you should have normalized
manually).
It was suggested that the project files to be moved to win32/, so that we can
have one less layer of directories we need to go down into to reach the project files.
Instead of relying on --generate-dependencies and the resource file,
actually list the resources in Make variables.
Fixes make not building new shaders because they're not inside the
resource file.
This node essentially implements the feColorMatrix SVG filter. I got the
idea yesterday after looking at the opacity implementation.
It can be used for opacity (not sure if we want to) and to implement a
bunch of the CSS filters.
...but disable them for now. Configs will be added for the projects to
support Vulkan-enabled builds which will then enable the builds of these
sources. Extra commands and items will be needed for the GSK resources
along with ensuring GSK_RENDERER_GSK being defined for the build of GDK,
GDK-Win32 and GSK so that the builds of Vulkan-enabled builds can be done
properly.
Filter out the Vulkan sources from the 'dist hook' rules in
gsk/Makefile.am as we don't want to in turn include them twice in the
projects when the 'make dist' is performed on a system with Vulkan
builds enabled.
One cannot use #if...#endif within macro calls in Visual Studio and
possibly other compilers, and there are more uses of VLAs that need to be
replaced with g_newa().
There were also checks for the clip type in gskvulkanrenderpass.c which
were possibly not done right (using the address of the type value to check
for a type value), which triggered errors as one is attempting to compare
a pointer type to an enum/int type.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Use g_newa() instead of VLAs, as VLAs may never be supported by some
compilers as it became optional in C11 and there are concerns about their
implementations in compilers that do support it.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
Forces a full redraw every frame.
This is done generically, so it's supported on every renderer.
For widget-factory first page (with the spinner spinning and progressbar
pulsing), I get these numbers per frame:
action clipped full redraw
snapshot 0ms 7-10ms
cairo rendering 0ms 10-15ms
Vulkan rendering 3-5ms 18-20ms
Vulkan expected * 0ms 1-2ms
GL rendering unsupported 55-62ms
* expected means disabling rendering of unsupported render nodes,
instead of doing fallback drawing. So it overestimates the performance,
because borders and box-shadows are disabled.
It's faster to render once for every rectangle in the clip region than
rendering the outline of the clip region.
Especially because this reduces the time necessary to build up the frame
data.
In widget-factory (where we have 3 rectangles), this leads to a 5x
speedup in the rendering time rendering alone.
Snapshotting time goes from 10ms to ~1ms, which is another huge
improvement.
Note: We interpolate premultiplied colors as per the CSS spec. This i
different from Cairo, which interpolates unpremultiplied.
So in testcases with translucent gradients, it's actually Cairo that is
wrong.
This is now tracking the clips added by the clip nodes.
If any particular node can't deal with a clip, it falls back to Cairo
rendering. But if it can, it will render it directly.
... and implement it for the Cairo renderer.
It's an API that instructs a renderer to render to a texture.
So far this is mostly meant to be used for testing, but I could imagine
it being useful for rendering DND icons.
That code doesn't do anything.
And what the code should be doing (clearing the abckground) isn't
necessary as cairo drawing is guaranteed to clear the surface.
This does a conversion to/from GBytes and is intended for writing tests.
It's really crude but it works.
And that probably means Alex will (ab)use it for broadway.
