[cairo] basic question?

[Charles سمير Doutriaux]

Hi Everyone,

In the end Carl was right for drawing intensive application, drawing  
to the image surface isn't any faster. And I'm now thinking maybe it  
was better to let the user see the drawing progress instead of staring  
at a blank screen... I'll have to rethink that one.

Anyhow, just one last remark on this. Carl when I use a a PixMap to  
draw onto. When I do the XCopyArea I still see the picture appearing  
slowly on the screen, whereas when I bring a "image_surface" back via  
Qt I see it appearing at once, is that expected? Should I use another  
function than XCopyArea?

Thanks again for all the help on this,

C.

On Aug 19, 2009, at 11:10 AM, Jamey Sharp wrote:

> On Wed, Aug 19, 2009 at 9:53 AM, Bill Spitzak<spitzak at gmail.com>  
> wrote:
>> For the normal displays Cairo has to be able to get the display to be
>> up to date after every single cairo call.
>
> Is that true? I don't see documentation calling for XFlush when using
> the Xlib backend, but there are no calls to XFlush in the cairo  
> source,
> and the only calls to XSync are during connection close. That seems
> appropriate to me: only the application can know when it cares about
> having its drawing happen.
>
>> It could also be used to queue up driver requests locally.
>
> This is, of course, exactly what Xlib and XCB do for you already,  
> and as
> you suggest, that's all about avoiding syscalls and context switches.
>
>> Tying this to the xlib flush is problematic as there are far too many
>> xlib calls that do it and that programs find it hard to avoid.
>
> Perhaps I'm mis-reading your comment. Xlib only flushes its buffer  
> when
> the buffer is full and you try to send more through it, or under  
> various
> circumstances around reading server responses. Those flushes are
> generally necessary to accomplish what you asked Xlib to do, and in a
> drawing-intensive setting it's the full-buffer case that's going to
> trigger flush most of the time. You really can't get around that.
>
> Looking at it the other way, the buffering is only an optimization.
> Forcing a flush early may be necessary for correctness, but delaying  
> one
> never is. And it isn't even obvious that it's a good optimization any
> more: if some of your CPU cores or your GPU are idle, then you  
> should be
> handing work off to them as early as possible instead of buffering  
> them
> longer.
>
> Jamey
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://*lists.cairographics.org/mailman/listinfo/cairo
>