From 698569f8428ca088f764d704034a1330517b98c0 Mon Sep 17 00:00:00 2001 From: tpearson Date: Sun, 26 Jun 2011 00:41:16 +0000 Subject: Finish rebranding of Krita as Chalk git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/koffice@1238363 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- chalk/doc/autoextending paintdevices | 54 ++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 chalk/doc/autoextending paintdevices (limited to 'chalk/doc/autoextending paintdevices') diff --git a/chalk/doc/autoextending paintdevices b/chalk/doc/autoextending paintdevices new file mode 100644 index 00000000..a42dc683 --- /dev/null +++ b/chalk/doc/autoextending paintdevices @@ -0,0 +1,54 @@ + +This is an attempt to explain how autosizing paintdevices work + +The tileddatamanager which is the underlying object that organizes the pixel +storage is autoextending. So it starts with zero tiles, and as writing is +being done new tiles are added as needed. + +There is also a default tile that is only readable (in theory). Whenever +access is only readaccess you get this tile for areas that don't have their +own tile yet. The idea is that the default tile is filled with transparent +pixels. (Or, with special layers like the background pattern or the selection, +with something else relevant. bsar) + + +So imagine a new image of size 640x640. The layer has no tiles, but when the +layer is being read (for viewing) we probe all over the image (640x640) and +read from the default tile wherever we probe. + +The extent of the layer (paintdevice) is 0x0 because nothing has been +written yet. + +Then some drawing is done in one corner and a tile is created automatically. +Now the extent is 64x64 (tilesize defined at compilation) because a single +tile exists. + +If some drawing is done in the opposite corner another tile is created. The +extent is now 640x640, but only two tiles exist (one in each opposite +corner). When probing for viewing the default tile is what you get except +for the two tiles. + +If we now apply a filer that lightens the colors (or something else) we +could iterate over the extent. That way we are sure to get all the real +tiles that have been created. + +As there is no way for us to know which pixel have true tiles and which have +the default, we would write to all the pixels within the extent, which would +automatically create ALL the tiles inside the extent. +(XXX: Of course, the tile manager could decide that the written value +is the same as the default value, and if that's true for all pixels in a tile, +not create a tile at all) (bsar)) + +In other cases like a gradient fill we would probably want to fill the +current image area, so we we would just write to the paintdevice, and tiles +would be automatically created for us. + +So in short: if you read - data will be available (either real tiles or a +default) - and if you write to the paintdevice - tiles will be created as +needed. So simply don't worry. + +But in some cases, when you want to modify already written pixels, as in +some filters you want to know where true data have been written. Otherwise +we would have to modify an infinite number of pixels to be sure everything is +changed. This is where the extent comes in handy. If you have absolutely +no leeway, use exactBounds which is slow, but sure. -- cgit v1.2.1