Hmm, so bugs are ok? Does this also include primitive (or plugib) failures which are handled correctly, but cause performance problems?
In particular, I'm thinking of primitive 103 in core (used in strikefont rendering), and plugin BitBlt using rule 41 (used in FTFont-rendering), whom (wild guess) both seem to have problem with the String -> ByteString/WideString refactoring... (IE: they fail in Pharo with a ByteString parameter instead of String, and use the strictly smalltalk fallback code resulting in... far worse performance) I tried installing VMMaker to investigate the problems further, but I guess the steps needed to set up an interpreter to properly test exactly what goes wrong in these cases were too advanced for me to figure out in 30 mins.. :( BTW, the Cuis subpixel-rendering looks beautiful (both performance and code-wise) compared to what is done in the FreeType code. Anyone have time to understand/integrate this approach before 1.0 release? Misc ideas: - How about inserting some sort of logging where primitives are called with failure, but Smalltalk code fallback is used for a seemingly successful result. then fixing the code/VM to handle those cases? Font rendering is the prime cultrip, but I'm sure there are other places as well.... Secondary: - How about another instance cache in Color, for transformed colours? Some of these transformed colours are used MANY times during each rendering step, (look at the senders of Color>>lighter f.ex.), it seems silly to create new Color object that have to be GC'd in many of these instances. In Pharo the overhead isn't very noticeable (due to the primitive failures mentioned above sucking up most of the processor time), but in a lean system like Cuis, they did appear on TimeProfiles... I'm not sure how much you can trust the leaf nodes of TimeProfiles though, at least in Cuis/(which I did most of my investigation in), they seemed to be spread at random between items in a block.... (IE: from one to another, it could shift from 90% in one method call to 90% in another method call in the same block). If you read this entire message, you have my condolances, and written permission to ask for clarifications :) Cheers, Henry , On 04.08.2009 16:44, Stéphane Ducasse wrote: > ok with me. > > Stef > > On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote: > > >> On Aug 1, 2009, at 18:33 , Marcus Denker wrote: >> >> >>> On 01.08.2009, at 07:06, Serge Stinckwich wrote: >>> >>> >>>> On Sat, Aug 1, 2009 at 2:41 AM, Stéphane >>>> Ducasse<[email protected]> wrote: >>>> >>>>> So what is the process now? >>>>> Do we focus on 1.0? >>>>> Can we integrate other issues? >>>>> Do we have a separate stream for 1.1 alpha? >>>>> >>>> Maybe the 1.1 alpha should be available after the release of Pharo >>>> 1.0 >>>> so the efforts of the team is not disseminate on two versions. >>>> >>> Yes, I think this is the way to go... we should force everyone to use >>> the >>> beta version for a while. >>> >> Yes. We have 50 open issues for 1.0 and when more people start using >> Pharo, they will find more bugs. So for now we should focus on >> bringing that number down to 0. >> >> Adrian >> >> >>> Marcus >>> >>> >>> >>> >>> -- >>> Marcus Denker - http://marcusdenker.de >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
