On 9 January 2014 12:54, J.F. Rick <s...@je77.com> wrote: > 'self changed' logic is the thing that triggers drawing. Before Athens, > various different morphs would register that their part of the screen > needed to be updated with a 'self changed' thing. Then, once a UI cycle, > the sum of the areas needing to be changed was determined and those morphs > within that area would be redrawn. So, you could have a 100 'self changed' > things happening before drawing happens. It seems like with Athens that > each 'self changed' causes a redraw. So, having 25 times as many self > changed messages causes 25 times as many drawing cycles. While Athens is > faster than BitBlt rendering, it may not be 25 times faster. > > Lets make things clear: Athens is responsible for drawing things on canvas. It is not responsible for what you drawing, when and where. Such things is beyond the scope of Athens. So, if there's a bug it could be related to some Morphic glue code (like in AthensWrapMorph etc). That is possible. And so, if you suspecting there's something wrong, look in that direction, and don't loose time trying to fix something in Athens because these things actually belong to morphic.
> Cheers, > > Jeff > > > On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko <siguc...@gmail.com> wrote: > >> >> >> >> On 9 January 2014 10:26, J.F. Rick <s...@je77.com> wrote: >> >>> OK. I've made a little headway in diagnosing the problem. It seems that >>> one culprit is that the "self changed" thing works differently with Athens >>> than previously. Correct me if I'm wrong, but it seems like sending that >>> method immediately causes the canvas to draw. In contrast, before, it just >>> marked that area as needing to be redrawn and then, on an update cycle, it >>> would redraw the total area that changed. I was using a model-view pattern >>> that had 25 components to it. When each got the update command, it seems to >>> have launched the canvas to draw. When I changed it so that only one >>> changed command was given, the interface became immediately much snappier. >>> Adding a factor of 25 to rendering could cause even fast rendering to be >>> quite noticeable. So, it is not an inherent problem with drawing forms but >>> rather one with changing the programming paradigm. Forms are just >>> noticeably slower to draw than vector components and that exacerbated my >>> problem. >>> >>> >> Hmm.. Can you explain me, how Athens is related to that? :) >> >> 'self changed' logic and its handling is related to Morphic and used by >> it. >> there's no way how you can change it by changing something in Athens. >> >> >> >>> Cheers, >>> >>> Jeff >>> >>> >>> On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <s...@je77.com> wrote: >>> >>>> Hmm. Weird. Could it be a linux thing? Bit order or something? Could it >>>> be a transparency issue? Could it be a size of the form? I have forms of >>>> size around 200 x 200. At this point, I haven't numerically investigated >>>> it. I just notice a significant difference in rendering speed as I switch >>>> from forms to SVGs. Perhaps it is having to redraw the entire interface >>>> very often. I'll investigate a bit more when I have some time. >>>> >>>> Cheers, >>>> >>>> Jeff >>>> >>>> >>>> On Thu, Jan 9, 2014 at 2:08 AM, Igor Stasenko <siguc...@gmail.com>wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 8 January 2014 08:59, J.F. Rick <s...@je77.com> wrote: >>>>> >>>>>> In good news, I was able to implement the S/s functionality and both >>>>>> of my SVGs now load properly. I'll try some more soon and commit the >>>>>> changes once I have tested it a bit more. >>>>>> >>>>>> In bad news, the cacheing was working properly, so I still suspect >>>>>> that rendering forms as a paint is too intensive to be practical for many >>>>>> applications. I'll try to evaluate it a bit more as I replace forms with >>>>>> SVGs. If the forms are causing the problem, then performance should >>>>>> noticeably increase. >>>>>> >>>>>> >>>>> I just did a little comparison: >>>>> >>>>> | surface time | >>>>> surface := AthensCairoSurface extent: 200@200. >>>>> >>>>> surface drawDuring: [ :canvas| >>>>> canvas setPaint: Color red. >>>>> canvas setShape: (0@0 extent: 100@100). >>>>> time := [ 10000 timesRepeat: [ canvas draw ] ] timeToRun. >>>>> ]. >>>>> time >>>>> 0:00:00:00.115 >>>>> ============= >>>>> >>>>> same as above but with: >>>>> canvas setPaint: (ThemeIcons current backIcon). >>>>> >>>>> time >>>>> 0:00:00:00.093 >>>>> =========== >>>>> >>>>> same as above but with: >>>>> (canvas setPaint: (ThemeIcons current backIcon)) repeat. >>>>> >>>>> time >>>>> 0:00:00:00.956 >>>>> >>>>> as you can see, even in slowest case, the throughput is: >>>>> >>>>> 100*100*10000 = 100'000'000 pixels (texels) per second. >>>>> >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Jeff >>>>>> >>>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Jochen "Jeff" Rick, Ph.D. >>>> http://www.je77.com/ >>>> Skype ID: jochenrick >>>> >>> >>> >>> >>> -- >>> Jochen "Jeff" Rick, Ph.D. >>> http://www.je77.com/ >>> Skype ID: jochenrick >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > -- Best regards, Igor Stasenko.
