Bug 57289

Summary:	Cairo context should provide cairo_set_target
Product:	cairo	Reporter:	Timothy Pearson <kb9vqf>
Component:	general	Assignee:	Chris Wilson <chris>
Status:	RESOLVED MOVED	QA Contact:	cairo-bugs mailing list <cairo-bugs>
Severity:	normal
Priority:	medium	CC:	andrej.mitrovich
Version:	1.12.8
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Timothy Pearson 2012-11-19 19:47:32 UTC

The cairo context cairo_t should provide a method to set the current target surface if the new target surface is compatible with the original target surface.

This new method would speed up drawing operations in a library I am working on; currently there is no way to either
1.) Change the cairo context target surface while keeping the state stack intact
-OR-
2.) Retrieve current or saved painter states and transfer them to a new context

I do not want to keep track of the various painter states inside my library due to the additional complexity and subsequent maintenance concerns.  As a result, I am essentially forced to draw onto an intermediate target surface, then paint the contents of that surface onto multiple target surfaces via slow compositing operations.

Comment 1 Andrej Mitrovic 2013-04-09 16:30:26 UTC

There was a proposal for cairo_/save/restore/_state[1] back in 2006, but it seems it never got implemented.

[1] : http://lists.freedesktop.org/archives/cairo/2006-January/006196.html

My needs are to be able to replace the target surface without losing internal state (such as the line width settings). For example I could have a widget with a backing store which a user paints on using a cairo_t context. If the widget size changes (e.g. becomes larger), the backing store might have to be reallocated, but then a new cairo_t context has to be created for the new surface.

Currently that means losing all internal stack state (e.g. the user's line width, etc). 

Either the ability to store and load the internal state externally or the ability to replace the internal surface would work for me.

Comment 2 GitLab Migration User 2018-08-25 13:37:01 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/99.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.