diff --git a/wiki/backend.html b/wiki/backend.html index ac7fb69c1..459454a1f 100644 --- a/wiki/backend.html +++ b/wiki/backend.html @@ -798,6 +798,33 @@ Files content is memory mapped into the process address space, this is managed b 
'FileHandleCache' storing a finite maximum number of [[FileHandle]]s as a list. As long the configured maximum of open files is not reached new file handles are stored at the begin of the list. Whenever a filehandle is accessed it is moved to the begin of the list too. Unused filehandles propagate towards the end of the list. When the maximum of open filehandles is reached, aged filehandles are closed and taken from the end.
+
+
Each 'FileMap' object contains many [[Frame]]s as well as metadata. The actual layout depends on the type of the [[File]]. Mappings need to be page aligned while [[Frame]]s can can be anywhere within a file and dynamic sized.
+
+All established [[FileMap]]s are managed in a FileMapCache. This is similar to the FileHandleCache but mappings which are in use are checked out of the aging list and thus become locked from aging/purging.
+
+FileMap objects are transparent to the application, it will only requests [[Frame]]s as in position and size (and some other parameters).
+
+
+
The 'FileMapCache' keeps a list of FileMaps which are currently not in use and subject of aging.
+Whenever a FileMap is in use, it is checked out into a in-use list where it is not subject of aging.
+
+
+
+
'Frames' are the smallest datablocks handled by the Backend. The application tells the Backend to make [[File]]s availabe and then only requests Frames from the Backend, all other datastructures of the backend are private.
+
+Actually Frames are blocks of continous memory, they can be anything depending on the usage of the [[File]] (Video frames, encoder frames, blocks of sound samples).
+
+Frames are referenced by a smart-pointer like object which manages the lifetime and caching behaviour. There are 3 states such a frame reference can be:
+# readonly: the backing FileMap is checked out from the aging list, frames can be read
+# readwrite: the backing FileMap is checked out from the aging list, frames can be read and written (depends on the filemode as well)
+# weak: the FileMap object is checked back into the ageing list, the frame cant be accessed but we can try to transform a weak reference into a readonly or readwrite reference
+
+Frames can be addressed uniquely (needs to be worked out) whenever a frame is not available, the backend can initiate a (probably recursive) render for it.
+
+Accessing [[Frame]]s may add further renderjobs for related frames to the [[Prefetch]] task.
+
+
/***
 |Name|FullScreenPlugin|
@@ -1211,12 +1238,12 @@ background rendering
 
 renderfarm
-
+
Whenever cinelerra needs to access data this is done through the DataBackend described here. The backend uses memory mapping to make data available to the program. This is little different to more common open/read/write/close file access while giving superior performance and much better memory utilization.
 
 The data backend must be capable to handle more data than will fit into the memory or even address space on 32 bit archs.  Moreover a project may access more files than the OS can handle at a time, thus the for [[File]]s used by the Backend it needs a FileHandleCache to manage filehandles dynamically.
 
-Which parts of a File are actually mapped to physical ram is managed by the kernel, but we keep a FileMapCache to manage the mappings we set up.
+Which parts of a File are actually mapped to physical ram is managed by the kernel, to keep a FileMapCache to manage the [[FileMap]]s we've set up.
 
 To minimize latency and optimize cpu utilization we have a [[Prefetch]] thread which operates a [[Scheduler]] to render and cache frames which are expected to be consumed soon. This prefetcher keeps [[Statistics]] for optimizing performance.