Re: [coLinux-devel] Re: Updated area.

[Henry N. <Hen...@ar...>]

Nuno Lucas wrote:
> Digital Infra, Inc., dando pulos de alegria, escreveu :
> 
>> Hello Lucas.
>>
>> Another stuff we should consider is, How to know updated area.
>> Updating whole fb each time is too slow.
>> Then, how to know what area to be updated.
>>
>> 1. Just expecting that an app tells the right area.
>> 2. Using a dirty bit of MMU.
>>    In this way, You can know which line to update, but not area.
>>
>> Your idea is welcome.
> 
> 
> I believe the key is implementing the accelerated functions for the FB 
> driver. They would update the frame buffer and add the area updated to 
> an "invalidate rect" queue.
> 
> As an example, the fb_fill_rect function in the fb_ops structure would 
> fill the given rect in the frame buffer memory and add the rect area to 
> the queue.
> 
> On the windows side, we would "add" this rects to get a single rect that 
> needs update.
> 
> If the queue is full, we either add all rects and leave the queue with 
> only the resulting rect, or just clear the queue and leave a full update 
> rect (could be a special case with all '0's - like Windows does).
> 
> On a later phase, we would use the windows functions for regions to 
> accomplish this. We add those rects to our invalidated region and use 
> the windows functions to update only that region.
> 
> The queue could also be optimized in the colinux side, so that no 
> redundant information is kept (like a fill_rect followed by a fill_rect 
> inside the previous rect).
> 
> This is only a first thought, a more through analysis must be done.
> 
> A rect would be defined by 4 32 bits uints, and could reside in free 
> space of the frame buffer. 16 bytes per rect implies we would only need 
> 4KB for a 256 entry queue, or 1KB for 64 entries (probably more than 
> enough).
> 
> In an even later phase we would need to replace the queue with an 
> operations queue, so we could accelerate 3D operations. This would make 
> the driver just a proxy for direct video card access (not memory, video 
> card operations, like GL or DirectX low-level operations).
> 
> We could also use the first int as a switch for other operations, like 
> if the 31th bit is set (<0), then it could be a special operation, 
> defined in the 127 following bits (for example, the beginning of a 
> triangle mesh for Open GL).
> 
> But this is only for the future, when we have access to the video memory 
> inside the linux kernel (I think it is possible, for future colinux 
> versions, to share this memory also).
> 
> Regards,
> ~Nuno Lucas

Nice ideas for optimizing rects.

All this works only, if acceloration is anabled.
But not all application using only acceloration functions.

I means, that new kernel have function fb_imageblit. Some older
application for kernel 2.4.x do not have this funtion and write into
buffer directly.

No problem: For this older program we can emulate a update of full
screen via timer.

I mistaken in thinking, because my last FB driver was for 2.4.20. I have
read vesafb today. This set of functions we need for minimal accelorated
implementaion.

Henry

> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>