- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
removing the area that is going to be rendered from the dirty area
before rendering it, prevents tile-handler-projection to render it
again.
This was the reason why caching showed an improvement also during
the construction of the projection. And it was a regression that
I introduced in a previous commit
when toggling the visibility of a single layer image with
alpha channel, zoomed at 50%, the projection wasn't
properly redrawn. It seems there's a GEGL bug exposed
by normal layer mode operation fast path.
measure the time it takes to render projection chunks and continue
rendering until 0.01 seconds have passed. This ways we avoid excessive
expose roundtrips.
so we can control how much time it takes, and can further optimize it.
This is needed for gtk3 because it should happen between clock ticks,
not in the expose handler, and in gtk2 the old code would have the
unfortunate property to potentially render at very high frame rates,
including all the overhead of exposing.
and separate the chunk rendering logic from the fact that it's invoked
from an idle callback. Idle rendering no longer works in GTK+ 3.8 and
later because the expose logic was changed from an idle function to a
frame clock, and when we switch to that in gtk3-port, the diff to
master should stay readable (and rebasable) in this critical part of
the code.
because it made applying of expensive filters pretty unresponsive.
Don't revert commit b7b504d624 tho
because it also moves the #defines to a proper place.
Let GimpTileHandlerProjection know how large the projection is so it
can calculate the number of levels in the pyramid, and always
invalidate all levels.
This does not make any difference for normal images, but for images
without display (like when creating thumbnails, or for GUI-less
scripting), this is now needed because we create the initial
projection much more lazily, and got an empty projection.
And along with it a lot of stuff like the drawable preview cache, the
gegl tile manager backend, temporary gimp_gegl_buffer_foo() stuff, and
the remaining bits of performance.
The projection is in an evil semi-ported state which makes it work
ok-ish for stuff like layer moving, but absolutely unbearable for
painting, there is also an off-by-one rendering glitch at some zoom
levels.
GIMP was doing evil hacks lying to GEGL about it's pixels being in a linear
color space when they are not. This causes incorrect rendering, makes gaussian
blur misbehave etc.
The legacy projection modes should be implemented using the same 2.2 gamma
formats that are correct to specify for sRGB data. (for proper color
management in higher bitdepths; icc backend babl formats should be used.)
For the old image modes correct babl formats are:
R'G'B'A u8 - 8 bit RGB with 2.2 gamma (sRGB) with linear alpha component
R'G'B' u8 - 8 bit RGB with 2.2 gamma (sRGB)
Y'A u8 - 8 bit Grayscale with 2.2 gamma with linear alpha component
Y' u8 - 8 bit Grayscale with 2.2 gamma
Y u8 - 8 bit linear data, used for masks/channels
A u8 - 8 bit linear alpha
-----------------------------------------------
RGBA float - 32bit floating point linear light RGB
RaGaBaA float - 32bit floating point linear light RGB, premultiplied alpha
to be used for processing that needs to scale by the alpha,
(blurs, resampling etc)
R'G'B'A float - 32bit floating point sRGB with gamma, to be used where
the result depends on being closer to perceptual when
processing, can be used a cheaper alternative to CIE Lab
based modes.
-----------------------------------------------
The legacy layer modes should use the formats with gamma 2.2 only for loading
and rendering legacy XCF files correctly, in the brave new world compositing
should most likely be done in linear light with "RGBA float" and even better
"RaGaBaA float" like GEGL does for porter duff and other compositing modes.
The ability to chose the legacy layer modes should probably be hidden from the
user unless an old .xcf has been opened.
During development, the GEGL code such have as much exposure to users testing
the development release. There is still the option to switch it off if GEGL is
not adhering to expectations.
Needed because a group layer's projection can have a different type
than its image, at least at some pathologic moment during image type
conversion. But even if it didn't, it's cleaner this way anyway.
* app/core/gimpprojectable.[ch]: add the new vfunc plus public API.
* app/core/gimpprojection.c: use it instead of using the type of the
image returned by gimp_projectable_get_image(). The get_image()
function is now unused in the projection and only needs to stay
because the projection is also a GimpPickable.
* app/core/gimpgrouplayer.c: implement GimpProjectable::get_image_type().
When the projectable's size or image type changes, stop the idle
renderer and remove all queued update area because everything needs to
be re-rendered anyway. Also honor the projectable's offset when
invalidating the entire projection after clearing the pyramid.
The only purpose of this change is to avoid having the "update"
signal twice on GimpGroupLayer (from GimpDrawable and from
GimpProjectable). Switch back to normal g_signal_connect()
in the projection.
Add/Subtract the projectable's offset whenever we go from coordinates
from our public interface (which are always image coordinates) and
coordinates in out internal tile pyramid (wihch always starts at 0,0).
The Gegl projection still needs an offset node that is missing.
Also, connect to the projectable's "update" signal using
g_signal_connect_closure_by_id() instead of simply g_signal_connect(),
so we really connect to the signal of the GimpProjectable interface
and not to the "update" signal of GimpDrawable (which is a conflict
that will happen on group layers).
