"That is not really helpfull. Anything that uses cairo? I would like to make some comparisons and it would help if I can recreate the same animations. (I did some work with cairo and python, but no animation. I used cairo for animations together with GTK, sure this was faster but these applications are only made for the animation, just a simple drawing loop. Pharo of course has much more that happens in between)."
No I was not talking as a developer but rather as a user, so by "everything" I mean literally everything I use, cairo based or not. I am no cairo developer , I only took a look at the pycairo docs once. I have picked the habit of taking a look at how much cpu each application consumes by using Blender. As you can imagine blender can eat cpu cycles like peanuts, so I have an overall idea under which circumstances the cpu can max out so I have learned to avoid it by utlising several techniques. I am also a blender python developer. But then its not hard to imagine that when you see a simple animation of a small logo slide in a very small area cosuming 30-50% of CPU and flicker, that 2d game running in full screen or even half screen would be a no go. On Sat, Mar 7, 2015 at 4:38 AM, Esteban Lorenzano <esteba...@gmail.com> wrote: > > On 07 Mar 2015, at 00:02, Nicolai Hess <nicolaih...@web.de> wrote: > > 2015-03-06 20:18 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>: > >> >> On 06 Mar 2015, at 18:40, kilon alios <kilon.al...@gmail.com> wrote: >> >> very good example and very informative thank you. >> >> Sadly it also shows that even with Athens Pharo is incredible slow. >> Simple animation spiking a single 3.2 Ghz core to 50% does not look very >> promising for heavy big size graphic based animations. Which is not a >> surprise since this was also evident the first time I tried the VGTiger >> demo. But still , its better than no Athens ;) >> >> >> That’s because we are converting the rendering into a bitmap that is >> after drawn for the vm… a complete inefficient mechanism. >> > > I heard this multiple times, but I still don't get it. The (cairo) > rendering happens on a (in memory) imagesurface. There is no extra > allocation > of a bitmap for every drawing on the screen. Drawing the rendering on the > screen is a bitblt (copybits) operation, like it is done for every other > Form. > > > I will try to explain… is a problem in several ways: > 1) what is not efficient at all is BitBlt plugin, our current way to > display things. Want an example? just open a new image, open a browser (or > a playground, or any window) and start moving it…. then watch how your cpu > starts heating (in my machine, is around 35%, some times… just one > browser). > 2) Now… what we do with Athens is: > a) create an in-memory surface and draw things there. > b) convert that surface into a bitblt compatible format (this is actually > just a copy, not much actually) > c) display the result into the current world window (another copy) > 3) Now imagine all that cycling (stepping)… > > With OSWindow (SDL2) what we do is: > 1) create a SDL2 surface > 2) draw on it > 3) cycle on (2) > > > >> I have a running experiment for drawing directly in the canvas (using >> SDL2 library) and the tiger demo drops from eating 70% of cpu to 9% in my >> machine. >> > > We can do this without SDL, but of course less platform independent, with > cairos win32 , quartz, or xrender (os dependent) surfaces. This is really > fast, no need > for an (in memory) image surface. But one problem with this approach is, > some morphs need to access the current displays Form data (HandMorph for > example). > And this does not work (or not easily) with the OS device surface. > Does this work with cairo and SDL? > > > yes, why not? > and yes… we can have several backends. The advantage on using SDL2 is that > you do not need to maintain one different backend for each platform. Of > course, it has also drawbacks, as always… but our manpower is determinant > here and we decided to take the “common approach”… we will have time to > improve later, if we find is necessary (but frankly, I do not think so for > the moment) > > > One thing that is really slow is painting an image with Athens, because > the cairo backend creates a new surface for this image and uses this > image as a pattern paint. The slow part is copying and converting the > image data into the surface. > I already proposed an alternative, (it's a bit like cheating), we can use > the bitblt to copy and convert the image data into the surface, this again > is much faster. > > > this is something inherent to cairo (and athens as a result)… I suppose > game programmers already dealt with this problem. I suggest look there for > answers (I didn’t look there, nor seen your proposed solution yet… sorry I > will as soon as I find some time). > > cheers, > Esteban > > > > >> Our idea is to move pharo in that direction for Pharo5 so next year we >> will be a lot better :) >> >> Esteban >> >> >> On Fri, Mar 6, 2015 at 6:28 PM, Alexandre Bergel <alexandre.ber...@me.com >> > wrote: >> >>> This is really good that you are diving into Athens. It deserves it! >>> >>> Alexandre >>> >>> >>> > On Mar 6, 2015, at 10:20 AM, Nicolai Hess <nicolaih...@web.de> wrote: >>> > >>> > There is a "play" button in the SketchBrowser. >>> > And if you open just the simple sketch view: >>> > ASketchExampleColors openView >>> > you'll have to start the drawing from the morph menu. >>> > >>> > In a prior version I had some "autoplay" option, but sometimes this >>> throws >>> > a NativeBoost error, if it is the first time it loads the cairo >>> library. >>> > >>> > Maybe I should add the autoplay again. >>> > >>> > >>> > >>> > >>> > 2015-03-06 16:03 GMT+01:00 Torsten Bergmann <asta...@gmx.de>: >>> > For me all the samples stay black. But the Athens tiger demo works... >>> > >>> > Is this a driver problem? >>> > >>> > Bye >>> > T. >>> > >>> > Gesendet: Freitag, 06. März 2015 um 10:14 Uhr >>> > Von: "Nicolai Hess" <nicolaih...@web.de> >>> > An: "Pharo Development List" <pharo-dev@lists.pharo.org>, "Any >>> question about pharo is welcome" <pharo-us...@lists.pharo.org> >>> > Betreff: [Pharo-dev] [ANN AthensSketch] A playground for drawings with >>> Athens. >>> > >>> > The main purpose of this packages is to ease the creation of simple >>> drawings and provide a rich set of examples for Athens drawing API. >>> > -------------- >>> > Gofer new >>> > smalltalkhubUser: 'NicolaiHess' project: 'AthensSketch'; >>> > configuration; >>> > load. >>> > ConfigurationOfAthensSketch loadDevelopment. >>> > >>> > AthensSketchBrowser open. >>> > >>> > ----------------- >>> > >>> > >>> > This is a simple playground for Athens drawings. Just subclass >>> AthensSketch and define your own sketch drawing in the #drawStepOn: method. >>> It provides basic frame based animation (play/pause/stop). >>> > >>> > Open a player with >>> > ASketchExampleColors openPlayer', >>> > or a simple viewer morph with >>> > ASketchExampleColors openView (start and stop rendering from the morph >>> menu) >>> > >>> > The AthensSketchBrowser lists all defined AthensSketch subclasses. >>> (Basic examples >>> > from package AthensSketch and some more examples from package >>> ASketchExamples). >>> > You can step through the list of examples, start and stop the drawing, >>> or view and edit the drawing code. >>> > >>> > It is great that we have now a vector based drawing API. The (old) >>> Canvas API is >>> > already great for pixel based drawings. A rich API and many good >>> things if >>> > you discover it. And Athens is a addition that can increase our >>> possibilities. >>> > There were some questions about Athens, what it is and what it is used >>> for, maybe this >>> > helps. >>> > >>> > >>> > nicolai >>> > >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> > >
