summaryrefslogtreecommitdiff
path: root/usage
diff options
context:
space:
mode:
authorVincent Sanders <vince@netsurf-browser.org>2009-04-08 10:17:09 +0000
committerVincent Sanders <vince@netsurf-browser.org>2009-04-08 10:17:09 +0000
commit056e1ebed94379db41ebb2e40cc88a873cfb4411 (patch)
treed1d01c4b9f9d4c2c2b1db4b705e631d49cf2e6b0 /usage
downloadlibnsfb-056e1ebed94379db41ebb2e40cc88a873cfb4411.tar.gz
libnsfb-056e1ebed94379db41ebb2e40cc88a873cfb4411.tar.bz2
initial commit of netsurf framebuffer library
svn path=/trunk/libnsfb/; revision=7060
Diffstat (limited to 'usage')
-rw-r--r--usage40
1 files changed, 40 insertions, 0 deletions
diff --git a/usage b/usage
new file mode 100644
index 0000000..7bb8d7d
--- /dev/null
+++ b/usage
@@ -0,0 +1,40 @@
+Framebuffer abstraction library
+-------------------------------
+
+This library provides a generic abstraction to a linear section of
+memory which coresponds to a visible array of pixel elements on a
+display device. The memory starts at a base location and is logically
+split into rows, the length of each row in memory is refered to as the
+stride length.
+
+The display device may use differing numbers of bits to represent each
+pixel, this represented by the bpp value and may be one of 1, 4, 8,
+16, 24 or 32. The library assumes packed pixels and does not support
+colour depths which do not correspond to the bpp. The 1bpp mode is a
+fixed black and white pallette, the 4 and 8 bpp modes use a 16 and 256
+entry pallette respectively and the 16, and 24 bpp modes are direct
+indexed RGB modes in 565 and 888 format. The 32bpp mode is RGB in 888
+format with the top byte unused.
+
+The library may be coupled to several display devices. The available
+devices are controlled by compile time configuration.
+
+Usage
+-----
+
+The library is initialised by calling nsfb_init() with the frontend
+type as a parameter. The nsfb_t pointer returned is used in all calls
+to the library. The geometry and physical settings may be altered
+using the nsfb_set_geometry() and nsfb_set_physical() functions. The
+frontend *must* then be initialised. The nsfb_set_geometry() and
+nsfb_set_physical() functions may be called at any time, however they
+are likely to fail once the frontend has been initialised.
+
+The nsfb_finalise() function should be called to shut the library down
+when finished.
+
+When directly acessing the framebuffer memory the nsfb_claim() and
+nsfb_release() calls should be used. These allow the frontends to
+syncronise access and only update the altered regions of the drawing
+area. Note the area claimed and released may not neccisarily be the
+same.