Subject:
Re: Re: [nanogui] patch for microwindows in wdtv live
From:
"yut616" ####@####.####
Date:
22 Feb 2010 16:27:29 -0000
Message-Id: <201002230026356984455@21cn.com>
see comments below.
2010-02-22
yut616
发件人： Greg Haerr
发送时间： 2010-02-22 09:57:47
收件人： yut616; nanogui
抄送：
主题： Re: [nanogui] patch for microwindows in wdtv live
Hi,
I have looked much more extensively at all the
changes that are in the WDTV source tree, based
on a release after 0.90, but before 0.91.
I see that you have been quite busy, and there
are still quite a few items that have been added,
which will need to be moved into 0.92 git in order
to use the current codebase. These items include:
o engine/devmalloc.c STATIC memory allocations
o static buffers for images
o NO_CHARMAP_WORKAROUND fix in font_freetype{2}.c
o drivers/scr_em86xx.c and scr_smp863x.c screen drivers
o MWROP_COPY_RK and MWROP_COPY_IK handling in 16 and 32bpp drivers
o TRANSLATE_ESC handling in kbd_tty.c
o brightness handling (requiring float) in devopen.c
o chinese font and HBF handling in freetype 2
o fast draw enhancements in devdraw.c::GdDrawImage
o jpeg setjmp and EOI handling
o png alpha channel and BGR handling
I am very interested in helping move all required
changes into the current pre-0.92 source tree,
but have some questions, which I've outlined
below. I would like to know whether you're
already trying to move to 0.92, given it
doesn't contain any of the features above (yet!).
Here are my comments on each of the above, in
more detail.
o engine/devmalloc.c STATIC memory allocations
o static buffers for images
These can be fairly easily handled by using
a specific memory allocator in all the image
routines, which could be redirected to your
STATIC_malloc() routines in devmalloc.c.
[TAO]
This is used for avoid the memory fragment.
o NO_CHARMAP_WORKAROUND fix in font_freetype{2}.c
I'm not quite certain what this is for, it appears
to handle character values > 0x80 differently. Can
you comment? Also, are you currently using
FT2, and which version? There have been many
changes adopted in FT2 since then, and the cache
code is now working in the repository.
[TAO]
you could see HAVE_FREETYPE_2_SUPPORT=Y at the bottom of config file which will overwrite the old value.
This should be font provider related, it could be ignored.
Sometimes, it will make a little change in these files for special font.
This feature is not enabled in config.
o drivers/scr_em86xx.c and scr_smp863x.c screen drivers
Are these drivers used in WDTV, or are you using
the fblin32.c and fblin16.c drivers?
[TAO] this is the driver for sigma 863x chipset, gfx.
o MWROP_COPY_RK and MWROP_COPY_IK handling in 16 and 32bpp drivers
These should be easily added to the fblin16 and fblin32 drivers.
o TRANSLATE_ESC handling in kbd_tty.c
Easily added
o brightness handling (requiring float) in devopen.c
The current implementation drags in floating point.
It would be nice to have a brightness control
capability that didn't require float.
[TAO] please ignore it, the first line of "case MWPF_TRUECOLOR565" is using a return.
o chinese font and HBF handling in freetype 2
Not sure if this is still required. Are these
mods, including the hbf.c files, still required
when using FT2 fonts? Are you using FT2 fonts
on the device, or only hbf.c and compiled-in
arial fonts?
[TAO] HBF is a Hanzi Bitmap font.
USE_HBF_FONT in src/drivers/genfont.c (used for BIG5 font)
Maybe it is helpful in some low cost embedded devices with small size LCD.
o fast draw enhancements in devdraw.c::GdDrawImage
I like this modification. However, in looking more
deeply, the speedup assumes a framebuffer display
and writes directly, bypassing the driver. This
won't work using non-fb display drivers. Thus,
I will need to apply a bit more work so that
your original speed improvement is held, and
the code works on any system (like X11 for test,
for instance).
We might add a flag, PSF_HAVEFB, to indicate whether
the GdDrawImage routine can draw directly or must
go through the screen driver for this operation,
for instance.
[TAO] please note the BPP32_COLOR2PIXEL/BPP32_DRAWPIXEL, which has no switch section in it.
o jpeg setjmp and EOI handling
I see there is also setjmp handling that is
new, for what reason? Is the reason for the EOI
handling that some jpegs are never received in
full, and that hangs the jpeg decoder?
[TAO] When extract image from mp3 id3 tag will cause this issue if the image is uncompleted.
setjmp could not handle the hang issue.
o png alpha channel and BGR handling
There is currently alpha channel support in
0.92RC2 that should work. However, there
isn't support for conversion to BGR format.
Is this to guarantee quick drawing the
GdDrawImage routine, or for another reason?
I would like a sample .png for testing.
[TAO] this png is 24bit, but with "tRNS Transparency"
This is related to the libpng, just a special case for 24bit png (IHDR Bitdepth: 8 ).
refer:
http://www.libpng.org/pub/png/spec/1.1/png-1.1.pdf
4.2.12 tRNS Transparency
According to PNG_EXPAND_tRNS to build in an alpha channel using trans_value.
When the RGB is same as trans_value's RGB, it will set ALPHA to 0, otherwise it will set 0xFF.
======================
libpng-1.2.14/pngrtran.c
png_do_expand()
(row_info->color_type == PNG_COLOR_TYPE_RGB && trans_value)
======================
BTW, png (with alpha channel) is much better for modern UI design than jpeg, PNG feature should be full supported.
I may have left out other requirements, please
let me know.
Regards,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
