[Gegl-developer] Re: [Gimp-developer] caching considerations in gegl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(soz if you get this multiple times, it hasn't turned up after ~24h)
Sven Neumann wrote:
looks very sane overall and I couldn't find any obvious design
mistakes. There is one thing that is already halfway implemented in

*cough* - completely implemented IIRC in respect to what it was
originally intended for. :)

the current system and that I'd like to see considered. I'm speaking
of a way to have hints about the pixel data stored in tiles. Such a
hint could for example state that the tile is completely transparent,
that it is fully opaque or even solid-colored.  We have this as
tile-row hints since GIMP-1.2 but I think it would make sense to have
such hints on the tile level as well. The cache system should probably
know about these hints since it wouldn't make much sense to swap a
solid-colored tile to disk since it can be regenerated faster than it
could be swapped in.

It's a reasonable direction, I think, but I have two comments:

* It probably makes sense to detect whether a whole tile is
transparent/solid/etc just-in-time when you're about to consider
swapping it out (or dropping it down to a colder cache) instead
of every time it gets dirty.  IIRC the tile-row-hints stuff does
this sort of stuff just-in-time too, at compositing time, so effort
isn't wasted on the various sorts of tiles, transient or otherwise,
that never end up getting composited (but I'm an old man and my
memory is getting hazy; I'd forgotten that the tile-row-hints
stuff even existed and I should bloody well know).

* For about a billion years I've been quite keen on the idea of
lazily strong-hashing dirty tiles into a gimp-global hash table
and collapsing multiple tiles with the same hash.  There are
so many hoops to jump through to make sure that the existing
copy-on-write framework can actually be used in certain situations,
mostly boiling down to having to use a central drawable-copy
function that knows when it's possible to COW.  Of course,
plenty of GIMP's operations don't/can't use this function but
still yield data that would in theory be COW-able.  The idea
of rehash-on-dirty would be to catch identical tiles, even
accidentally-identical tiles (like great masses of transparent
tiles, presuming that you scrub the RGB data of a transparent
pixel; the row-hints stuff has been doing this and potentially
breaking the ill-advised anti-erase feature for 100 years now
and no-one has complained), that the normal COW routes miss.

Since I suck, I don't have time to implement... stuff.  But these
are probably fun beginners' core-hacking projects.

--Adam
--
Adam D. Moss   . ,,^^   adam@xxxxxxxx   http://www.foxbox.org/   co:3
busting makes me feel good
kthx bye




[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux