Hi henrik what I suggest is: cut your messages into smaller ones so that we can get multiple and clear thread. Then enter bug items when needed.
Stef On Aug 5, 2009, at 12:49 AM, Henrik Sperre Johansen wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
