[PATCH] fbcon: new scrolling mode: YPAN + REDRAW
Added a new scrolling mode (SCROLL_PAN_REDRAW) to fbcon that should greatly benefit unaccelerated drivers such as VESA fbdev. An increase of 3-10 times in scrolling speed can be expected. Currently, fbcon has 4 different scrolling methods (1-4). Potentially, we can have 6. This patch implements SCROLL_PAN_REDRAW (5). SCROLL_WRAP_REDRAW (6) is still unimplemented. Scroll Mode Operation YPan YWrap +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1. SCROLL_ACCEL copyarea No No 2. SCROLL_REDRAW imageblit No No 3. SCROLL_PAN copyarea Yes No 4. SCROLL_WRAP copyarea No Yes 5. SCROLL_PAN_REDRAW imageblit Yes No 6. SCROLL_WRAP_REDRAW imageblit No Yes +++++++++++++++++++++++++++++++++++++++++++++++++++++ Note 1: I've changed the nomenclature to increase clarity: SCROLL_ACCEL = SCROLL_MOVE SCROLL_REDRAW = SCROLL_REDRAW SCROLL_PAN = SCROLL_PAN_MOVE SCROLL_WRAP = SCROLL_WRAP_MOVE To demonstrate the effect of each of the scrolling methods on an unaccelerated PCI/AGP-based driver (vesafb), I used a simple benchmark (time cat linux/MAINTAINERS - a 50K text file). The framebuffer is set at: 1024x768-8bpp, 8x16 font, yres_virtual = 2*yres 1. SCROLL_MOVE: real 5m50.277s user 0m0.001s sys 5m50.227s Almost 6 minutes for a 50K text file. Using soft copyarea on a PCI-based card is just too slow (because copyarea has to read from the framebuffer memory). 2. SCROLL_PAN_MOVE scrollmode: SCROLL_PAN real 0m8.592s user 0m0.000s sys 0m8.586s Using ypan with copyarea dramatically improves the scrolling. However, the scrolling action is jerky (fast during the panning stages, slows down during the copyarea stages). 3. SCROLL_REDRAW (this is the default scrolling mode) real 0m3.189s user 0m0.000s sys 0m3.170s Simply eliminating the copyarea, even without ypanning, makes it faster than SCROLL_PAN_MOvE. Plus, the scrolling action is smoother. So, if we combine YPanning with imageblit (PAN_REDRAW), we get this: 4. SCROLL_PAN_REDRAW real 0m0.520s user 0m0.000s sys 0m0.518s That's almost 6x faster than SCROLL_REDRAW. Increasing the amount of video RAM still increases the speed, but not very dramatically. Higher than 16 MB, the increase is negligible. Using an accelerated driver, we see almost the same effect but not as dramatically: 1. SCROLL_MOVE - accel real 0m3.112s user 0m0.000s sys 0m3.112s 2. SCROLL_REDRAW - accel real 0m2.604s user 0m0.000s sys 0m2.603s Redraw is still faster than move, but not much. 3. SCROLL_PAN_MOVE - accel real 0m0.203s user 0m0.000s sys 0m0.202s 4. SCROLL_PAN_REDRAW - accel real 0m0.326s user 0m0.002s sys 0m0.323s This is one exception. If panning is enabled, move is actually faster than redraw. As to why, I don't know. So based on the above, fbcon will choose the scrolling method based on the following preference: Ypan/Ywrap > accel imageblit > accel copyarea > soft imageblit > (soft copyarea) Note 2: Exception: accel copyarea > accel imageblit if Pan/Wrap is enabled. Note 3: soft copyarea will be avoided by fbcon as much as possible unless there is a specific override, ie., FBINFO_READS_FAST flag is set. If this flag is set, fbcon will prefer copyarea over imageblit, accel or soft. As a final note, in order for fbcon to use the best scrolling method, the low-level drivers must provide the correct hinting by setting the FBINFO_HWACCEL_* flags. To vesafb users: boot vesafb like this for fastest scrolling action: video=vesafb:ypan,vram:16 Signed-off-by:Antonino Daplas <adaplas@pol.net> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment