John-Mark Bell wrote: > Thanks for the update. I'll attempt to find time tomorrow to look at > your changes. > thanks :-) >> when that is merged, the gtk uploads branch would need reviewing one day >> too; >> > This is presumably just the frontend file upload hooks, right? > it should be, mainly; of course the merger of uploads branch is less important in the sense of 'constant progress in areas affecting all of NetSurf' than the main gtk branch is >> 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? > I'll prepare a set of screenshots - hopefully before 0900 BST :-D >> 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? > More screenshots planned :-) >> 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. > good news then :-D > J. > Best regards
Mark http://www.halloit.com Key ID 046B65CF
