Hi All,
I'm doing porting/developing GTK+(2.13.4)/DirectFB(1.0.0) acceleration
project on linux/arm11 board with internal graphic coprocessor.
For this, I've implemented new gfxdriver(G) module with new system(S)
module which is based on existing fbdev system and both utilize our
internal graphic device.
Those two modules support RGB16 format only at this starting stage.
'G' has (DFXL_FILLRECTANGLE | DFXL_DRAWRECTANGLE | DFXL_DRAWLINE |
DFXL_FILLTRIANGLE) and (DFXL_BLIT | DFXL_STRETCHBLIT) acceleration
capability with no fx drawing nor fx blitting (DSDRAW_NOFX,
DSBLIT_NOFX.)
With these new module, gtk-demo application shows improper update for
specific updating.
If there are anyone interested in my case and/or kind enough to read
followings, please give me your advice on it.
As you might know, gtk-demo shows demo list at left pane with
highlighted background color(RGB=0x107ce8 ~ sky blue) and inverted font
color for focusing item.
When gtk-demo try to move and update focusing item (for example, from
1st item to 2nd item), 1st item should change to normal status and 2nd
item should change to focused status (highlighted background with sky
blue color and inverted font color).
But, my implementation shows improper images for them.
And, when I set our gfxdriver(G) to report that it has no blit
acceleration capability, focus updating works fine.
It seems came from that
1. gtk-demo do test DFB's ability at gtk_init() stage to determine
their window fixel-format.
2. for this, _gdk_visual_init() test if DFB has DFXL_BLIT ability with
some pixel formats.
3. when gfxdriver(G) provide no blit function, it choose DSPF_ARGB to
fallback into S/W one.
4. when gfxdriver(G) provide blit function, _gdk_visual_init() choose
last format among their test formats, that is DSPF_RGB332.
5. when gfxdriver provide blit function and _gdk_visual_init() choose
DSPF_RGB332 for their internal window format,
it shows black-outed area for hight updating.
6. _gdk_visual_init() could be made to choose DSPF_ARGB by hack
gfxdriver(G) to report that no blit is available for testing
pixel-formats.
( the testing is done with 8x8 surface, so gfxdriver could report no
blit is available only for that format testing.)
cf. _gdk_visual_init() has bug and crush at run-time if there are not
blit compatible format before blit compatible format in their test
formats.
7. But, both case 5) and 6) could not show proper updating for moving
highlight item as 3) shows.
8.1 in the case of 3), it just do followings:
-do S/W fallback gBlit
with DSBLIT_BLEND_ALPHACHANNEL, DSBF_SRCALPHA for source
blend-option, DSBF_INVSRCALPHA for dest blend-option
from system area surface(ss0) with DSPF_ARGB to video card internal
area surface(vs) with DSPF_RGB16.
-do S/W fallback gBlit
with DSBLIT_NOFX,
from video card internal area surface(vs) with DSPF_RGB16 to video
card display area surface(primary surface) with DSPF_RGB16.
-and shows proper update.
8.2 But, in the case of 6), it do followings:
-do prepare new update area on system area main surface(ss0):
create new small surfaces(ss1, ss2, ss3, ...) in system area with
DSPF_A8 format,
and gBlit them into system area main surface(ss0)
-do S/W fallback gBlit
with DSBLIT_BLEND_ALPHACHANNEL, DSBF_SRCALPHA for source
blend-option, DSBF_INVSRCALPHA for dest blend-option
from system area surface with DSPF_ARGB to video card internal area
surface with DSPF_RGB16.
-do S/W fallback gBlit
with DSBLIT_NOFX,
from video card internal area surface with DSPF_RGB16 to video card
display area surface with DSPF_RGB16.
-and shows improper update.
Thanks reading long description above.
My question is like:
What made DFB choose different methods for the case 6) from 3) ?
Why DFB core do not update properly for the case 6) ?
Thanks & Regards,
Jessie
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
