i think we should completely revert because it's faster for us. and then
look to reduce the number of invalidations, which will make it even faster.
-jo
On Sat, Jan 10, 2015 at 5:50 AM, Roman Lebedev wrote:
> I have asked about this issue in #gtk+:
>
>> [19:10:57] hmm, should there any differe
I have asked about this issue in #gtk+:
> [19:10:57] 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() ?
> [1
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
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 wrote:
> I found the culprit for this regression.
>
> Roman, can you have a look? The patch below give a big slowness to dt
> in da
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
Date: T
Am 09.01.2015 um 11:04 schrieb Pascal Obry:
> 2015-01-09 8:48 GMT+01:00 johannes hanika :
>> for me this is only the case with opencl, the cpu code path seems to update
>> a lot more promptly.
>
> So maybe we should add a small delay in the OpenCL path?
>
This is already done today. You can tune th
Here the sliders are sluggish with both CPU and GPU code. It's debatable
if the CPU code is a little bit more responsive here. However, the
effect is marginal compared to the drastic loss compared to darktable-1.6.x.
Ulrich
Am 09.01.2015 um 08:48 schrieb johannes hanika:
>
>
> On Fri, Jan 9, 20
2015-01-09 8:48 GMT+01:00 johannes hanika :
> for me this is only the case with opencl, the cpu code path seems to update
> a lot more promptly.
So maybe we should add a small delay in the OpenCL path?
--
Pascal Obry / Magny Les Hameaux (78)
The best way to travel is by means of imaginatio
On Fri, Jan 9, 2015 at 11:48 AM, Pascal Obry wrote:
> Le jeudi 08 janvier 2015 à 21:34 +0100, Ulrich Pegelow a écrit :
> > don't know if this has already been discussed.
> >
> > With current master all sliders have an extremely sluggish behavior.
> > Take a module with some demands in CPU cycles
Le jeudi 08 janvier 2015 à 21:34 +0100, Ulrich Pegelow a écrit :
> don't know if this has already been discussed.
>
> With current master all sliders have an extremely sluggish behavior.
> Take a module with some demands in CPU cycles (like shadows &
> highlights) and try to quickly move around
No crashes here (so far).
Maybe it has something to do with how often the slider emits a
value-changed signal. If it happens too often darktable continues to
reprocesses the image...
We had that behavior in the past with gradientsliders. That's the reason
why I added timeouts (with g_add_timeo
maybe it has something to do with the gdk lock? not sure it still works as
we remember it from gtk2. if i move sliders a lot, i usually get the
attached crash (independent of slider).
-jo
On Fri, Jan 9, 2015 at 9:34 AM, Ulrich Pegelow
wrote:
> Hi,
>
> don't know if this has already been discuss
12 matches
Mail list logo
