I have asked about this issue in #gtk+:
> [19:10:57] <LebedevRI> hmm, should there any difference in e.g.
> performance/responsiveness if i draw on cairo_t *cr passed into draw()
> callback (gtk3) v.s. if i create similar surface, draw on it, and then
> paint it on the cr that passed into draw() ?
> [19:12:42] <> it depends
> [19:13:31] <> drawing on the cr GTK gives you may happen on an accelerated
> surface. the cairo_t is also already clipped, so cairo can discard geometry.
> [19:14:26] <> if you just take an image surface and use it as a source,
> cairo will blit the contents of the surface (taking the clip into account)
> [19:17:25] <LebedevRI> interesting. the issue i'm experiencing here is
> that second path (cairo_image_surface_create + cairo_create +
> cairo_set_source_surface + cairo_paint) results in slightly more responsive
> gui
> [19:20:32] <LebedevRI> so, if i correctly understood you, it should be the
> other way around, plain drawing on passed cairo_t *cr should be at least
> not slower, right?
> [19:23:11] <> no
> [19:23:19] <> I said that it depends
> [19:24:03] <> if you have complex drawing that you can offload to a
> separate surface, or even a separate thread, then you won't block the main
> loop in ::draw
> [19:24:16] <> and that may result in a more responsive UI
> [19:24:57] <> you also may achieve the same with a proper invalidation
> region and partial redraws. or maybe not.
> [19:25:07] <> as I said, "it depends"
> [19:26:01] <LebedevRI> yes, that i know, i think, now we invalidate way
> too much
> [19:28:15] <LebedevRI> ok, thank you, that is more or less what i wanted
> to hear, it should give us an idea of next steps...
Some findings:
1. partial revert of 1d01d51d979826da179a0d1b8908dfbd91b6fe83 will
indeed fix *some* sluggishness
2. we need to recheck all the gui invalidation code
(like gtk_widget_queue_draw()), and redo it with a proper invalidation
regions and partial redraws. it will also fix navigation panel blackouts
<https://github.com/darktable-org/darktable/pull/810>.
Since 1. will mask the issue, i think we should try to start from 2.
Roman.
On Fri, Jan 9, 2015 at 6:51 PM, johannes hanika <hana...@gmail.com> wrote:
> indeed it looks like reverting that might be a good idea. probably writing
> through to the currently displayed cairo object triggers all kinds of
> exposure/display callbacks all the way down to the screen and writing to
> double buffers, right after every stroke operation (as opposed to doing
> that just once in the end).
>
> cheers,
> jo
>
> On Fri, Jan 9, 2015 at 3:43 PM, Roman Lebedev <lebedev...@gmail.com>
> wrote:
>
>> Hello.
>>
>> I'll look, but the real issue here is that we probably request full
>> redraw of all widgets way too often.
>>
>> Roman.
>>
>> On Fri, Jan 9, 2015 at 5:37 PM, Pascal Obry <pas...@obry.net> wrote:
>>
>>> I found the culprit for this regression.
>>>
>>> Roman, can you have a look? The patch below give a big slowness to dt
>>> in darkroom mode.
>>>
>>> It can still be reverted from master. And indeed just reverting it
>>> makes dt fly again!
>>>
>>> commit 1d01d51d979826da179a0d1b8908dfbd91b6fe83
>>> Author: Roman Lebedev <lebedev...@gmail.com>
>>> Date: Tue Dec 30 20:55:26 2014 +0300
>>>
>>> Draw callbacks: cairo drawing cleanup. Part 1.
>>>
>>> Only simplest stuff for now - drop unneeded temporary surfaces.
>>> Might result in slightly smaller memory footprint.
>>>
>>> --
>>> Pascal Obry / Magny Les Hameaux (78)
>>>
>>> The best way to travel is by means of imagination
>>>
>>> http://v2p.fr.eu.org
>>> http://www.obry.net
>>>
>>> gpg --keyserver keys.gnupg.net --recv-key F949BD3B
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> darktable-devel mailing list
>> darktable-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/darktable-devel
>>
>>
>
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
darktable-devel mailing list
darktable-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/darktable-devel
