This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well. I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense. Anyway, for most of my applications, switching over to vector-based graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there. First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented. Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence. Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should. Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg <http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Hi rick Thanks for your email :)
This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well.
No igor is not like that. He loves to see people using what he did and improving in case so please continue. This is the best motivation for igor.
I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense.
Yes because the buffer is copied several times around. Igor and Ronie started laste thursday an effort to see how to shortcut all the buffers to speed up the system.
Anyway, for most of my applications, switching over to vector-based graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.
Yes!!!!
First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.
I remember that he started to add some functionalities that were not supported by Cairo like arc something.
Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.
Igor will give you access to commit because we need more people helping and improving.
Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.
Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg - This one fails because of vLineTo: and hLineTo: button-erase.svg - This one fails because of reflectedCubicBezier curves.
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 6 January 2014 19:31, J.F. Rick <self@je77.com> wrote:
This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well.
Quite opposite. You using Athens abd helping to polish it. What could be better?
I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense.
Right. Converting Form(s) to paint(s) is memory intensive operation. Basically, it copies contents of the form to newly created surface. To avoid this, use caching. Here is an example from ImageMorph:
drawOnAthensCanvas: aCanvas | cached | cached := aCanvas cacheAt: image ifAbsentPut: [ image asAthensPaintOn: aCanvas. ]. aCanvas setPaint: cached. aCanvas paintTransform restoreAfter: [ aCanvas paintTransform translateBy: self innerBounds origin "negated". aCanvas drawShape: self innerBounds. ]. without caching, rendering morphic desktop was very slow, since all icons is forms. Anyway, for most of my applications, switching over to vector-based
graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.
First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.
Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.
Can you submit the fix, please? Let me know if you need commit rights .
Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.
should be straightforward: vLineTo: number ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [ 0@number ]) hLineTo: number ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [ number@0 ])
Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg<http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves.
You mean this one?:
*S/s * (shorthand/smooth CurveTo) x2,y2 x, y Draw a cubic Beizer curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point (x2, y2) on the previous command relative to the current point. Yes. Not supported. Yet :) But it should be quite easy to implement. Jochen, i need help with completing SVG importer. So, if you can help, please do. Can you tell me what is your login name on smalltalkhub, so i will add you to http://smalltalkhub.com/#!/~Pharo/Athens committers?
On Tue, Jan 7, 2014 at 11:22 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Right. Converting Form(s) to paint(s) is memory intensive operation. Basically, it copies contents of the form to newly created surface. To avoid this, use caching. Here is an example from ImageMorph:
drawOnAthensCanvas: aCanvas
| cached |
cached := aCanvas cacheAt: image ifAbsentPut: [ image asAthensPaintOn: aCanvas. ].
aCanvas setPaint: cached.
aCanvas paintTransform restoreAfter: [ aCanvas paintTransform translateBy: self innerBounds origin "negated".
aCanvas drawShape: self innerBounds. ].
without caching, rendering morphic desktop was very slow, since all icons is forms.
Yes. I had figured that out. Unfortunately, even with cacheing, it was slow after enough images were open. It could be that, for whatever reason, my cacheing code is not working, but I doubt it. It looks pretty exactly like that.
Anyway, for most of my applications, switching over to vector-based
graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.
First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.
Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.
Can you submit the fix, please? Let me know if you need commit rights .
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick.
Third, while ASPathConverter supports vLineTo: and hLineTo:,
AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.
should be straightforward:
vLineTo: number ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [ 0@number ])
hLineTo: number ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [ number@0 ])
Great. Works like a charm. The swap shapes one now works fine. I can also include that in a commit.
Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg<http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves.
You mean this one?:
*S/s * (shorthand/smooth CurveTo)
x2,y2 x, y
Draw a cubic Beizer curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point (x2, y2) on the previous command relative to the current point.
Yes. Not supported. Yet :) But it should be quite easy to implement. Jochen, i need help with completing SVG importer. So, if you can help, please do.
Can you tell me what is your login name on smalltalkhub, so i will add you to http://smalltalkhub.com/#!/~Pharo/Athens committers?
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick. I can take a shot at implementing the S/s thing. If you have any URLs that would be helpful for getting started, please send them my way. Otherwise, I'll just try to find some documentation on Cairo and SVG. That seems like the major obstacle. Cheers, Jeff PS I know my name is confusing. My surname is Rick. My forename is Jochen, but I go by Jeff for English speaking people. -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 7 January 2014 19:25, J.F. Rick <self@je77.com> wrote:
On Tue, Jan 7, 2014 at 11:22 AM, Igor Stasenko <siguctua@gmail.com> wrote:
Right. Converting Form(s) to paint(s) is memory intensive operation. Basically, it copies contents of the form to newly created surface. To avoid this, use caching. Here is an example from ImageMorph:
drawOnAthensCanvas: aCanvas
| cached |
cached := aCanvas cacheAt: image ifAbsentPut: [ image asAthensPaintOn: aCanvas. ].
aCanvas setPaint: cached.
aCanvas paintTransform restoreAfter: [ aCanvas paintTransform translateBy: self innerBounds origin "negated".
aCanvas drawShape: self innerBounds. ].
without caching, rendering morphic desktop was very slow, since all icons is forms.
Yes. I had figured that out. Unfortunately, even with cacheing, it was slow after enough images were open. It could be that, for whatever reason, my cacheing code is not working, but I doubt it. It looks pretty exactly like that.
what object you using as a key for cache? because if its temporary object, then its useless.
Anyway, for most of my applications, switching over to vector-based
graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.
First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.
Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.
Can you submit the fix, please? Let me know if you need commit rights .
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick.
Okay, i added you. Wellcome.
Third, while ASPathConverter supports vLineTo: and hLineTo:,
AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.
should be straightforward:
vLineTo: number ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [ 0@number ])
hLineTo: number ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [ number@0 ])
Great. Works like a charm. The swap shapes one now works fine. I can also include that in a commit.
Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg<http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves.
You mean this one?:
*S/s * (shorthand/smooth CurveTo)
x2,y2 x, y
Draw a cubic Beizer curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point (x2, y2) on the previous command relative to the current point.
Yes. Not supported. Yet :) But it should be quite easy to implement. Jochen, i need help with completing SVG importer. So, if you can help, please do.
Can you tell me what is your login name on smalltalkhub, so i will add you to http://smalltalkhub.com/#!/~Pharo/Athens committers?
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick. I can take a shot at implementing the S/s thing. If you have any URLs that would be helpful for getting started, please send them my way. Otherwise, I'll just try to find some documentation on Cairo and SVG. That seems like the major obstacle.
I use W3C/SVG.. i don't think there's any better/more complete and more comprehensive source than official one :)
http://www.w3.org/TR/SVG11/ Cheers,
Jeff
PS I know my name is confusing. My surname is Rick. My forename is Jochen, but I go by Jeff for English speaking people.
hehe.. i typed Jeff at first, but then looked at your profile picture
which says 'Jochen Rick' and corrected it :)
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Best regards, Igor Stasenko.
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. Cheers, Jeff On Tue, Jan 7, 2014 at 7:42 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 7 January 2014 19:25, J.F. Rick <self@je77.com> wrote:
On Tue, Jan 7, 2014 at 11:22 AM, Igor Stasenko <siguctua@gmail.com>wrote:
Right. Converting Form(s) to paint(s) is memory intensive operation. Basically, it copies contents of the form to newly created surface. To avoid this, use caching. Here is an example from ImageMorph:
drawOnAthensCanvas: aCanvas
| cached |
cached := aCanvas cacheAt: image ifAbsentPut: [ image asAthensPaintOn: aCanvas. ].
aCanvas setPaint: cached.
aCanvas paintTransform restoreAfter: [ aCanvas paintTransform translateBy: self innerBounds origin "negated".
aCanvas drawShape: self innerBounds. ].
without caching, rendering morphic desktop was very slow, since all icons is forms.
Yes. I had figured that out. Unfortunately, even with cacheing, it was slow after enough images were open. It could be that, for whatever reason, my cacheing code is not working, but I doubt it. It looks pretty exactly like that.
what object you using as a key for cache? because if its temporary object, then its useless.
Anyway, for most of my applications, switching over to vector-based
graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there.
First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented.
Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence.
Can you submit the fix, please? Let me know if you need commit rights .
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick.
Okay, i added you. Wellcome.
Third, while ASPathConverter supports vLineTo: and hLineTo:,
AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should.
should be straightforward:
vLineTo: number ^ self lineTo: (absolute ifTrue: [ endPoint x@number ] ifFalse: [ 0@number ])
hLineTo: number ^ self lineTo: (absolute ifTrue: [ number@endPoint y ] ifFalse: [ number@0 ])
Great. Works like a charm. The swap shapes one now works fine. I can also include that in a commit.
Here are two examples of the kind of SVG files I would like to read: button-swapShapes.svg<http://home.cc.gatech.edu/je77/uploads/1/button-swapShapes.svg> - This one fails because of vLineTo: and hLineTo: button-erase.svg<http://home.cc.gatech.edu/je77/uploads/1/button-erase.svg> - This one fails because of reflectedCubicBezier curves.
You mean this one?:
*S/s * (shorthand/smooth CurveTo)
x2,y2 x, y
Draw a cubic Beizer curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point (x2, y2) on the previous command relative to the current point.
Yes. Not supported. Yet :) But it should be quite easy to implement. Jochen, i need help with completing SVG importer. So, if you can help, please do.
Can you tell me what is your login name on smalltalkhub, so i will add you to http://smalltalkhub.com/#!/~Pharo/Athens committers?
Thanks. I'd love to contribute. My SmalltalkHub Id is JochenRick. I can take a shot at implementing the S/s thing. If you have any URLs that would be helpful for getting started, please send them my way. Otherwise, I'll just try to find some documentation on Cairo and SVG. That seems like the major obstacle.
I use W3C/SVG.. i don't think there's any better/more complete and more comprehensive source than official one :)
Cheers,
Jeff
PS I know my name is confusing. My surname is Rick. My forename is Jochen, but I go by Jeff for English speaking people.
hehe.. i typed Jeff at first, but then looked at your profile picture
which says 'Jochen Rick' and corrected it :)
-- 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
On 8 January 2014 08:59, J.F. Rick <self@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.
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 <siguctua@gmail.com> wrote:
On 8 January 2014 08:59, J.F. Rick <self@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
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. Cheers, Jeff On Thu, Jan 9, 2014 at 8:18 AM, J.F. Rick <self@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 <siguctua@gmail.com> wrote:
On 8 January 2014 08:59, J.F. Rick <self@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
On 9 January 2014 10:26, J.F. Rick <self@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 <self@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 <siguctua@gmail.com> wrote:
On 8 January 2014 08:59, J.F. Rick <self@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.
'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. Cheers, Jeff On Thu, Jan 9, 2014 at 10:36 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 10:26, J.F. Rick <self@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 <self@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 <siguctua@gmail.com>wrote:
On 8 January 2014 08:59, J.F. Rick <self@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
On 9 January 2014 12:54, J.F. Rick <self@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 <siguctua@gmail.com> wrote:
On 9 January 2014 10:26, J.F. Rick <self@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 <self@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 <siguctua@gmail.com>wrote:
On 8 January 2014 08:59, J.F. Rick <self@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.
Sure, but getting the glue between Athens and Morphic right is important if we want Morphic to successfully use Athens. I'll investigate it sometime and see where the problem lies. BTW, I'm starting to work on the SVG thing. There definitely are a few things missing from the specification. For instance, opacity does not work that well. I'll just see what bugs I find and try to put solutions to them together. One thing that occurred to me is that we may want to think about abstracting a bit up from the SVG format. Could we have a more universal vector format that can be read from an SVG and can be written to an SVG but could also have other applications (e.g., Postscript)? What I am thinking of is something along the lines of forms. They can be written out as JPGs or PNGs but they aren't very JPG or PNG like when you are using them. Cheers, Jeff On Thu, Jan 9, 2014 at 1:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:54, J.F. Rick <self@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 <siguctua@gmail.com>wrote:
On 9 January 2014 10:26, J.F. Rick <self@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 <self@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 <siguctua@gmail.com>wrote:
On 8 January 2014 08:59, J.F. Rick <self@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.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 9 January 2014 17:32, J.F. Rick <self@je77.com> wrote:
Sure, but getting the glue between Athens and Morphic right is important if we want Morphic to successfully use Athens. I'll investigate it sometime and see where the problem lies.
BTW, I'm starting to work on the SVG thing. There definitely are a few things missing from the specification. For instance, opacity does not work that well. I'll just see what bugs I find and try to put solutions to them together. One thing that occurred to me is that we may want to think about abstracting a bit up from the SVG format. Could we have a more universal vector format that can be read from an SVG and can be written to an SVG but could also have other applications (e.g., Postscript)? What I am thinking of is something along the lines of forms. They can be written out as JPGs or PNGs but they aren't very JPG or PNG like when you are using them.
Yes, some kinds of objects hierarchy which form a scene (which if rendered form a picture, and transferring it to any kind of media don't costs too much).
In case of Athens it could any object, since you need from object to be compatible with Athens is understand #drawOnAthensCanvas: protocol. Cheers,
Jeff
On Thu, Jan 9, 2014 at 1:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 9 January 2014 12:54, J.F. Rick <self@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 <siguctua@gmail.com>wrote:
On 9 January 2014 10:26, J.F. Rick <self@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 <self@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 <siguctua@gmail.com>wrote:
On 8 January 2014 08:59, J.F. Rick <self@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.
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Best regards, Igor Stasenko.
participants (3)
-
Igor Stasenko -
J.F. Rick -
Stéphane Ducasse