For painting this issue got mostly evaded by the new graph code, but my plan prior to that was to add a _blit() and _copy() function to projection and use that in the spots that just want to pull pixel data out of it. That will give it enough information about the request size to be smart, while still keeping the ability to only render part of the results (e.g. when doing the on canvas preview).

The one snag to that I haven't solved (but plan to) is that we need to expose the logic GeglBuffer uses to calculate linear input to it's scale functions. I need to do that anyways to implement scale properly in gegl_node_blit.

Generally, downsampling should be done in linear light. Not, however, upsampling.
If the samplers are standing in the way, I suggest that you let them eat nonlinear light and implement the desirable conversion, which generally is different for the up and downsampling components of the samplers, within the sampler code.
(Emphasis on "suggest".)
Nohalo BTW does not convert. The upsampling component probably would look better if it used nonlinear light.

Nicolas Robidoux Senior Research Scientist
www.phaseone.com

Note: the internal conversions could be approximate as long as they are close to reversible.
And this could only be a temporary fix because most likely downsampling would become very slow.

On Sun, Jun 16, 2013 at 9:47 AM, Nicolas Robidoux < nicolas.robidoux@gmail.com> wrote:

Generally, downsampling should be done in linear light. Not, however, upsampling.
If the samplers are standing in the way, I suggest that you let them eat nonlinear light and implement the desirable conversion, which generally is different for the up and downsampling components of the samplers, within the sampler code.
(Emphasis on "suggest".)
Nohalo BTW does not convert. The upsampling component probably would look better if it used nonlinear light.

I do not think Daniel is not referring to ramplers; but the built in scaling logic of the mipmap pyramids.

/

Maybe this is out of place, but speaking of tiles, I noticed that several compositing packagings and 3D renderers draw the tiles outwards from the center of the image. Some programs even offer preferences for different tiles drawing.
Outwards from center seems to be faster (actually it's a perceived faster, not real faster) than rows from top left to bottom right. I think that drawing the tiles outwards from the center of the view would provide a huge boost in perceived performance, because you'd always be seeing the first tile in the visible. Right now if you're looking at the bottom of an image and the top is beyond the visible area, you have to wait for the tiles to be drawn, and in slow operation that's perceived like extra slowness.

Is this even planned or considered? Is it possible?

Sorry if this question adds noise to the thread, this has been on my head for several days and I needed to ask.

Gez.

On Mon, Jun 17, 2013 at 3:33 AM, Guillermo Espertino (Gez) < gespertino@gmail.com> wrote:

I think that drawing the tiles outwards from the center of the view would provide a huge boost in perceived performance, because you'd always be seeing the first tile in the visible. Right now if you're looking at the bottom of an image and the top is beyond the visible area, you have to wait for the tiles to be drawn, and in slow operation that's perceived like extra slowness.

Is this even planned or considered? Is it possible?

GIMP is rigged up to first render the visible area and then the rest - GEGL hasn't made us of this yet. Ideally only the visible area at display resolution is rendered this is something that would require changes in both how GIMP interfaces with GEGL as well as having an implementation of GEGL providing the capability... so yes this has been on the agenda for a while.

/

The future is already here. It's just not very evenly distributed
                                                 -- William Gibson
http://pippin.gimp.org/                            http://ffii.org/

On Mon, 2013-06-17 at 03:59 +0200, Øyvind Kolås wrote:

On Mon, Jun 17, 2013 at 3:33 AM, Guillermo Espertino (Gez) < gespertino@gmail.com> wrote:

[...]

Right now if you're looking at the bottom of an image and the top is beyond the visible area, you have to wait for the tiles to be drawn, and in slow operation that's perceived like extra slowness.

That's true in gimp 2.8 or older too, e.g. if you do curves you see the result much sooner at the top left corner of a large image.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Hello Guillermo,

Am 17.06.2013 03:33, schrieb Guillermo Espertino (Gez):

Some programs even offer preferences for different tiles drawing.
Outwards from center seems to be faster (actually it's a perceived faster, not real faster) than rows from top left to bottom right.

i've stumbled across this effect, too. When the update is running along two wavefronts, it seems the mind is valuing the halved distance more than the halved speed. At least that's how i like to explain this to myself ;)

Possibly related, there are some tricks to improve the perceived duration when it comes to progress bars: http://www.chrisharrison.net/index.php/Research/ProgressBars2

best regards, yahvuu

On 18.06.13 at 10:46 PM yahvuu wrote

Possibly related, there are some tricks to improve the perceived duration when it comes to progress bars: http://www.chrisharrison.net/index.php/Research/ProgressBars2

Ah, the well-known effect from Windows (since Vista I think) and KDE ;-) But yes, things seem to go faster.

IMHO we should also consider the following: - For all progress indicators in GIMP use the same widget for visual consistency. In GIMP since 2.8 this is the green round progress indicator (the 'green ball') at the mouse cursor (for instance seen in the Tools).
- As soon as possible return to a state where the user can continue her/his work. This means: in the (blocking) foreground only process what the user imperatively needs to continue her/his work and use the progress indicator only for this. The remain of the operation is done in the background. This would not only appear to be faster, but really be faster and thus achieve the product visions goal of a high working speed.

Kind regards,

Sven

On Wed, 2013-06-19 at 06:20 +0200, scl wrote:

- As soon as possible return to a state where the user can continue her/his work. This means: in the (blocking) foreground only process what the user imperatively needs to continue her/his work and use the progress indicator only for this.

+1

One I particularly dislike is the cursor grab for select by colour - on a large image you might wait quite some time (tens of seconds or longer) before you can use the mouse pointer again. I looked at patching this but the code was far from obvious, sorry.

The remain of the
operation is done in the background. This would not only appear to be faster, but really be faster and thus achieve the product visions goal of a high working speed.

Another image editor :) does this a lot, updating the preview and then working on the main image in the background.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml