Friday, May 8, 2009

Krita's tilesystem project idea

Some days ago i've thought over my GSoC project for Krita. Here are my ideas how to refactor KisTilesDataManager.

I'll begin with the lowest level: KisTile. New KisTile class will be an abstraction of a tile that doesn't store the actual data of the image itself (actual data is stored in tile-data object, that can be shared by several tiles). Tile-class will encapsulate locking and copy-on-write mechanisms.
Tile-data objects are created by special class that is in charge of storing, compressing and swapping data. It's name is KisTileDataStore. Tile-data objects are stored in linked list. New objects always added in the tail of the list so swapper thread can walk from head to tail and swap out old stuff; the old stuff will be accessed first.

Let's imagine the situation when we need to access some tile for read.
  1. We call tile->acquireForRead
  2. It acquires tile->m_tileData->m_RWLock for read
  3. Checks whether tile->m_tileData->m_state==NORMAL
    a) if not calls tileDataStore->getTileDataToMemory
  4. Allows user to read tile->m_tileData->m_data

Access for write:
  1. We call tile::acquireForWrite
  2. It acquires tile->m_tileData->m_RWLock for write
  3. Checks whether m_refCount==1 (we are the only user of tile-data)
    a) m_refCount--
    b) if not, COW. tile->m_tileData = tileDataStore->allocNewTileData()
  4. Checks whether tile->m_tileData->m_state==NORMAL
    a) if not calls tileDataStore->getTileDataToMemory()
  5. Allows user to read tile->m_tileData->m_data

Creating new tile object (KisTile::KisTile):
  1. tile->m_tileData = tileDataStore::getDefaultTileData()
    defaultTileData object is shared by all tiles, so it has m_refCount field higher than 1, so it'll be replaced by a new tile-date on the first write request.

1 comment:

  1. Interesting, I'm not a programmer but I wonder how this goes along with the other plans in the future, such as collaborative editing...

    ReplyDelete

Followers