| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
Determine whether a css value is 'static' at creation
time. Static values don't need to have compute() called,
since their value is always the same, so we can just
ref them.
|
|
|
|
|
|
| |
The differenciation between a literal color value and an RGBA value
caused problems in various situations. Just treat the two the same but
don't allow access to the rgba value of a non-literal color value.
|
|
|
|
|
|
|
| |
Some css parser tests were relying on the parser preserving
some units. Update them. The numbers look uglier this way,
but they are the same numbers the css machinery was using
anyway.
|
|
|
|
|
|
| |
The computation we do for angles and times does not
depend on the context, and can be done at creation
time.
|
|
|
|
| |
We now print colors differently in some places.
|
| |
|
| |
|
|
|
|
|
|
| |
Just like font features, font variations are stored
as a hash table mapping strings to pure number values,
which never change during compute.
|
|
|
|
|
|
|
|
| |
Font features consist of a hash table of number
values, which will never change during compute,
so there is no point in recreating a new value
with a copy of the hash table, constaining the
same string->number mapping.
|
| |
|
|
|
|
|
| |
The values 5px, 6px, 7px, 0.15s, 0.2s and 0.3s
all show up in high numbers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we create a GtkCssShadowsValue for just one shadow, just return that
show value instead and allow calls on GtkCssShadowsValue API on one
shadow. That saves us around 480 GtkCssShadowsValue instances in the
widget factory.
css value stats before:
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
SUM: 7872
and after:
GtkCssShadowsValue: 107
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2764
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 883
SUM: 7395
7872 to 7395 is a 477 reduction (6.0%)
|
| |
|
|
|
|
|
|
|
|
|
| |
we don't need to do the calculation at all if the progress is 0 or 1
anyway.
We also sometimes transition from 0 to 0 etc., so we can short-circuit
that as well by doing the fast pointer-equality check and relying on the
singletons.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most corners are square, so x == y. In that case, just accept either of
them. This makes the corner value unnecessary.
In fact none of the corner values in the widget-factory are needed, so
this spares us around 500 corner value allocations.
css value stats before:
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssCornerValue: 556
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
SUM: 8428
and after:
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
SUM: 7872
8428 to 7872 is a 556 reduction (6.5%)
|
|
|
|
| |
given that we parse an array, chances are we're gonna see 2 values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just allow calling _get_nth() and _get_n_values() on every kind of css
value. This way we can allow all values in places where only array
values would be allowed before.
This spares us around 1000 array values in the widget factory.
css value stats before:
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssCornerValue: 556
GtkCssArrayValue: 1130
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
GtkCssColorValue: 1452
SUM: 9415
and after:
GtkCssBgSizeValue: 23
GtkCssIdentValue: 25
GtkCssPositionValue: 81
GtkCssCornerValue: 556
GtkCssArrayValue: 143
GtkCssStringValue: 33
GtkCssPaletteValue: 29
GtkCssImageValue: 2765
GtkCssColorValue: 1452
GtkCssFilterValue: 3
GtkCssRgbaValue: 1092
GtkCssShadowValue: 708
GtkCssEaseValue: 33
GtkCssBorderValue: 2
GtkCssTransformValue: 11
GtkCssDimensionValue: 882
GtkCssShadowsValue: 584
SUM: 8428
9415 to 8428 is a 987 reduction (10.4%)
|
| |
|
|
|
|
|
| |
The values of these are never gonna change so we can as well create
literal color values from the resulting colors instead.
|
| |
|
| |
|
|
|
|
| |
gitlab reads the new filename but not the old one.
|
|\
| |
| |
| |
| | |
fixed layout: Actually set child transforms
See merge request GNOME/gtk!1292
|
| |
| |
| |
| |
| |
| | |
The code was unintentionally appending to the
existing child transform, leading to ever-moving
children when you call gtk_fixed_put.
|
|\ \
| | |
| | |
| | |
| | | |
quartz: impl_class->set_functions listed twice in the object
See merge request GNOME/gtk!1283
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | | |
Move `[NSApplication sharedApplication]` after event loop init to avoid window focus issues (closes #2342).
See merge request GNOME/gtk!1286
|
|/ /
| |
| |
| |
| |
| | |
avoid initialization issues
(cherry picked from commit 46c2451c5a3cd42aa5a94935bfc850a484288ff3)
|
|\ \
| |/
|/|
| |
| | |
gsk/gsktransform.c: Fix building on non-GCC
See merge request GNOME/gtk!1291
|
|/
|
|
|
|
|
| |
sincosf() is really a GCC-specific function that may more may not be
supported on non-GCC compilers, so we want to check for it, otherwise we
use a fallback implementation, not unlike the one in
demos/gtk-demo/gtkgears.c.
|
|
|
|
|
| |
We can handle this pretty easily by normally drawing the other
(visible) child node, if any.
|
| |
|
|
|
|
| |
Private and unused function.
|
|
|
|
|
| |
If the epsilon we use there is too much, we can run into rendering
errors because the GPU will use the actual scale value.
|
|
|
|
|
| |
Otherweise we floor() implicitly when casting to int, resulting in
slight scaling later.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Make these two code paths look the same.
|
|
|
|
|
| |
it's confusing that we use GtkStyleContext here while we use the CssNode
directly elsewhere.
|
| |
|
|
|
|
| |
We can even replace the comment this way.
|
|
|
|
| |
And avoid every single function prototype.
|
| |
|
| |
|
|
|
|
| |
Otherwise we might get mapped again with a half-transparent cursor.
|
|
|
|
|
|
| |
The junction doesn't make sense when we use indicators, since the
scrollbars overlap anyway. Not snappshotting it anymore has no visual
effect since it's being drawn below the scrollbars anyway.
|
|
|
|
| |
This makes it clear that the !repeating case is easier.
|
|
|
|
|
| |
We handlet the common easy cases manually anyway, so don't bother
sqrt()ing the x/y coords in those cases.
|