On Sun, 2009-08-09 at 12:17 +0200, Mark wrote:
> Hi,
> 
> well the 'main' gtk branch should now be more ready for merger as I have
> hopefully implemented all of John-Mark's very constructive suggestions
> to make the code more robust;

Thanks for the update. I'll attempt to find time tomorrow to look at
your changes.

> when that is merged, the gtk uploads branch would need reviewing one day
> too;

This is presumably just the frontend file upload hooks, right?

> as for windows branch, the 'clear screen' code that was necessary to
> make the background redraw properly, particularly when scrolling, caused
> unacceptable flickering; I had to change that particularly for the case
> of gifs that caused flickering redraw loops at page load; now I've
> simplified the screen clearing to allow the core to simply redraw the
> page rather than utterly erasing it first, the background redraw bug has
> reappeared; it *looks* as though the core is forgetting background
> elements that it has drawn, although the chances are it's more connected
> to the communication from the core to the screen
> 
> Be that as it may, I'm hopeful it'll be addressed, possibly I'll need
> the assistance of those who may recognise the bug :-)

I'm not sure I recognise it from your description. Can you be more
specific?

> then there are the wayward 'images' that seemed to have appeared
> originally when jpegs were being rendered to screen undecoded; so unless
> it's connected to libmng - that I'll hope to cross-compile as I'll be
> looking into liblcms - then it may be a case for 'those who may
> recognise the bug' :-D

What is "wayward" about them?

> the good news is that windows branch now renders the main image types
> including alpha-channel transparency, although the overhead for partial
> transparencies of calculating an rgb value - that seems to work at a
> reasonable speed in development - may be heavy for older machines, so a
> conditional simpler implementation may be necessary

If it can be done on 40MHz of ARM, there's precisely no reason why x86
shouldn't be able to cope.


J.


Reply via email to