GitLab

Now users can download pixels and make everything slooooooow.

I want to reuse the name gsk_texture_download() for downloading the
actual bytes.

... 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.

Just query it locally.

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.

The function was removed when gsk_render_node_draw() was and
gsk_renderer_realize() was refactored respectively.

Takes a rendernode file, outputs a PNG. Nothing more.

I'll need it in tests/testsuite soon.

Now we can select buggy nodes, save them to a file, and add that file to
our testsuite.

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.

I had originally thought I'd use GskShadow for box-shadow, but didn't in
the end.

So now it's only used for text-shadow and icon-shadow, and those don't
have a spread.

The only thing still drawn with Cairo are grid lines.

The big fat scary bin drawing function that actually draws the cell
renderers - that one is still missing.

VLAs are not supported by Visual Studio and possibly other compilers that
are supported by GTK+-3.90+, and probably never will be, although it is a
C99 specification, and it became optional for C11.  It is also not a part
of the newer compiler requirements that are listed out for GTK+-3.90.x.

There exist concerns about the implementation of VLAs in compilers that
support them as well, so change it to a g_newa() approach.

https://bugzilla.gnome.org/show_bug.cgi?id=773299

Instead of a separate allocation for any arrays in the render node
we allocate these as part of the render node itself, using C99
flexible arrays.

This leads to less allocations, which is nice, but the major reason
for this is that it allows us to change the allocation scheme further
in the future. For instance, we want to do stack-like allocation so
that all the render-nodes for an entire frame are allocated in one
(or a few) chunks.

Instead of constantly recalculating this (especially recursively for
parents!) we do it only on construction, because everything is
immutable anyway. Also, most nodes had a bounds already and can
use the new parent member instead.

We also do direct access to the node bounds rather than calling
gsk_render_node_get_bounds in various places, which means
we do less copying.

(cherry picked from commit e0856226)

This causes the snapshotting algorithm to dump all widget nodes into
their own container node. We then name that group accordingly (ie
"GtkSwitch<0xdeadbeef>") so you can easily see which node belongs where.

The feature is toggleable in the inspector's visual tab.

There's a few problems with it, becuse GtkSnapshot optimized container
nodes away if they are not needed, so we are losing some widgets...

The revealer needs to clip the child during animations, whcih draw() did
automatically, but snapshot() does not.

It's equivalent to gtk_container_propagate_draw() and then one is
public, too.

We have no more pixel cache, so they are kind of useless.

https://bugzilla.gnome.org/show_bug.cgi?id=776306

When the first/last color stop is not at 0%/100%, we need to start the
repeating at their offsets and not at 0%/100%.

Attached reftest demonstrates the problem.

And with it, remove the draw func from custom gadgets, that has been
NULL everywhere.

All gadgets are snapshot now.

Instead of making people intiialize a rectangle and then applying border
radius manually, provide a constructor that does it for them.
While doing that, also allow people to instead request the padding box
or the content box.

Refactor all relevant code to use this new constructor.