A stepping stone, the translation was accidentally dropped when
changing the clipping to be performed first.
Fixes twin.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
For an unbounded surface we cannot assume (0, 0, surface_width,
surface_height) as that is wrong and causes the operation to appear
clipped.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Gah, I thought about this and noted that I need the inverse of the
normal transformation, yet failed to remember to actually use it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
This allows us to actually clip out the geometry before we record it, as
suggested by allowing the user to supply an extents... But it will be
advantageous in later patches for reducing the amount of work we need to
perform to replay.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Being called with no clip, might be unexpected, but it means to fill the
whole extents with the opacity. So do so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Computing the exact bbox of the glyphs and whether they are overlapped
is expensive. However, we can often check whether they are visible just
by looking at the maximal extents of the fonts along with the bbox of
the positions; much cheaper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Introduced recently in a30a7402f7,
==32234== Conditional jump or move depends on uninitialised value(s)
==32234== at 0x6BCA326: _cairo_surface_wrapper_needs_device_transform (cairo-surface-wrapper.c:549)
==32234== by 0x6BCB47D: _cairo_surface_wrapper_set_inverse_transform (cairo-surface-wrapper.c:579)
==32234== by 0x6BCB55A: _cairo_surface_wrapper_init (cairo-surface-wrapper.c:621)
==32234== by 0x6BB87A6: _cairo_recording_surface_replay_internal (cairo-recording-surface.c:854)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
During replay we want to handle recording surfaces specially, and not
redirect the creation of those to the target surface. This is similar to
the need to keep image surfaces as images during replay.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order to avoid the copy and transformation of the single rectangle,
we can simply pass it to pixman and create the region from it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In the simple condition where the user is applying an opacity mask to a
misaligned rectangle, we can treat it as a series of simpler composites
by combining the opacity with the coverage of the box.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
백현기 reported a use-case where he was recording an entire web-page
onto the recording surface, in order to facilitate panning. In this
scenario, where there may be lots of similar surfaces within the
recording we generate thousands of unused snapshot-images bloating
memory usage and impairing performance.
Under the right conditions we can replay directly onto the destination
which not only bypasses the snapshots but also skips the following
resampling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
b132fae5e8 introduced the usage of two
new pixman formats. This requires pixman 0.22, but makes it possible
to fix some TODO's left behind in gl and vg.
This is basically the same fix as e6c3efdd65. However, this was lost in
b132fae5e8 and thus had to be fixed again.
Fixes: clip-fill-eo-unbounded clip-fill-nz-unbounded
Signed-off-by: Uli Schlachter <psychon@znc.in>
Device mutexes guarantee the consistency between multiple threads,
hence GC cache does not rely anymore on atomic operations.
This makes it possible to avoid bit twiddling and to use a simple
array.
As we do not control the geometry used for the individual glyphs, we
must always send a clip-region so that X can trim the glyph
appropriately. However, in order to avoid sending unnecessary data we
only do so if the clip extents is less than the ink extents of the
glyphs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
