On Fri, Oct 21, 2016 at 3:41 PM, Tudor Girba <tu...@tudorgirba.com> wrote:
> Hi Clement, > > Thanks for raising this question. > > In short, Sparta is inspired from Athens and it has a similar structure. > So, there is an in-image interface of the canvas, and there is a concrete > implementation through the plugin (based on Moz2D). To target a completely > in-image rendering, it is certainly possible to implement a BitBlt backend > of the Sparta canvas. To implement this part, we would need help. > > The goal is indeed to have only one canvas in the default Pharo > distribution: Sparta. However, this will not happen suddenly. Ideally, when > Pharo 6 will be released, there will be a beta version of Sparta + Bloc + > some tools that will be loadable externally. Then my guess is that it will > still take another year until we get the full development environment > working on top of Sparta. So, it is to be expected that this transition > will take at least 1.5 years during which time Athens will still provide > the option of running on top of BitBlt. > > Does this answer the concern? > It does. I understand a BitBlt back-end is possible to have UI applications running on a low memory footprint runtime. Now the question the community should answer is if we want to implement and maintain that back-end or not. > But, now my question: Would it not be possible to get the VM to not open a > window when in headless mode? > I would love to see that. It's theoretically possible, it's just a matter of doing it and integrating it while it's time-consuming. I believe there was some work in that direction as part of the SDL / OSWindow work. If the community wants to move to Sparta and does not care if the memory footprint is increased by 5 Mb for non headless application, it may make sense to invest in that direction instead of the implementation and maintenance of a BitBlt based back-end. > > Cheers, > Doru > > > On Oct 21, 2016, at 2:23 PM, Clément Bera <bera.clem...@gmail.com> > wrote: > > > > > > > > On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <alex.sy...@gmail.com> > wrote: > > Hi Stéphane > > > > Indeed, build is broken :) > > Yesterday I took a very brief look at bloc and can confirm that > development version is loadable in Pharo 6 and is completely Sparta based. > (all examples work for me) > > > > You are right, live environment on embedded systems is great goal to > achieve. Sparta must not prevent pharo from getting there. It is true that > plugin is relatively big (windows 7mb, osx 15mb, linux 18mb). However, it > is all-in-one build and size can be reduced dramatically. > > > > As I understand, Pharo for PC should not make any assumptions about > user's hardware. If gpu accelerated backend can not be used there should be > still a performant fallback backend which also needs a fallback that is > guaranteed to work even on Personal Calculators. (Taschenrechner). That is > why library is so big. For example for mac and windows Sparta is shipped > with 3 (!) backends that together build fallback chain, for instance on > windows: direct2d1.1, skia, cairo. Compiling library for mac without Skia > reduces binary size from 15mb to 10mb. Removing GL package and leaving only > software backends may reduce size even more. > > > > It is a bit different on embedded systems, since hardware configuration > is already known and there is no need to have so many fallback backends. > Library itself allows developers to add new exotic backends quite easily. > > > > Let's take Pharo6 for mac. It is shipped with the following libs: > > Cairo (1.4mb) + Pixman (2.8mb) + Freetype (0.8mb) = 5mb > > > > Moz2D is self contained and does not require any additional libs. > > Moz2D = 15mb, Moz2D without Skia = 10mb. Moz2D without Skia and GL = ? > (estimate around 6-7mb). > > > > As you can see we get almost the same numbers :) > > > > Yeah but none of the libs (Cairo, Pixman, FreeType) are required to run > Pharo, they're required only if you use them. I compile VMs without such > libraires and Pharo works just fine as a development environment and for > simple things like web servers. The Squeak VM for example have around 2Mb > footprint in total, including 1Mb for the C runtime (initialized and > uninitialized data, executable code) and 1 Mb for the machine code zone and > can run most Pharo features just fine, including for examples web services > and the IDE. > > > > Right now the VM cannot start completely headless, the headless mode > just hides the main window, so if the main window start-up depends on > Sparta, it's not possible to run Pharo headless without many Mb of memory > footprint. > > > > Which leads the first question... > > > > >> Is it possible to start your Bloc Pharo image on a 2Mb footprint VM ? > By asking this question, I imply, if there is no > Cairo/Pixman/FreeType/Sparta plugin, can the image run headless and can it > run UI applications ? > > > > The last problem is that Pharo can currently run UI application like the > IDE on a 2Mb memory footprint VM. Let's assume Pharo with Bloc/Sparta/etc. > can be run either headless on a 2Mb memory footprint VM or with a UI on a > 7Mb+ memory footprint VM. It means now people doing UI would need extra > memory, for example, in the case of android deployment where the android > app includes the VM and the image, the app memory consumption at runtime > would be at least 5Mb bigger. > > > > >> Is the community ok with this or will we need to maintain both the > Sparta back-end and a Bloc to BitBlt back-end as a fall-back to run on > smaller VMs ? > > > > > > Cheers > > Alex > > > > On Oct 19, 2016 22:16, "stepharo" <steph...@free.fr> wrote: > > Hi Aliaksei > > > > It looks gorgeous. > > I tried to launch the Bloc image from the CI and it crashes during > startup on my mac. I reported that to Glenn and Alain but so far I simply > cannot see Bloc code. Is it working for you? I mean is it me that is using > the wrong VM. > > > > Then I have a question: > > > > - do you think that we can have a fallback in terms of back end for > the case where we could like to run Pharo on coffee machines but get a live > environment on such machines? This is related to the discussions we got > this summer about the memory footprint that Moz2D will put on us. > > > > I do not mean that we must have one but I think that this is important > to check because we can say that Pharo is small but if we need 20 mb > libraries for rendering there are some cases where this can kill its usage. > > > > Stef > > > > Le 19/10/16 à 18:06, Aliaksei Syrel a écrit : > >> Hi > >> > >> I am happy to announce the release of Sparta v1.1 for Pharo 6. > >> https://github.com/syrel/Sparta/tree/v1.1 > >> > >> It can be bootstrapped with the following script: > >> > >> Metacello new > >> > >> > >> baseline: 'Sparta' > >> ; > >> > >> repository: 'github://syrel/sparta:v1.1/src' > >> ; > >> > >> load: #file:core > >> Examples are on class side of: MozExamples, MozTextExamples > >> (for linux users: if you use 32bit pharo on 64bit linux, sparta will > not work, since 32bit plugin depends on 32bit GTK which conflicts with > 64bit GTK. Either use 32bit linux or 64bit pharo. I tested sparta with > 64bit vm on mac and linux - it works, but some features fail because FFI is > not ready) > >> Release of v1.1 is focused on hardware acceleration, windows support > and text rendering. > >> What is new: > >> - Default backends on all platforms changed from software to hardware > accelerated. > >> - Now also works on Windows! Default backend is Direct2D for drawings > and DirectWrite for text. On multi-gpu machines per-app-default setting is > respected. In case of Nvidia it can be changed in nvidia control panel. > Sparta is x2 faster on discrete gpu than on integrated one. > >> - Added initial text support, for instance rendering and high > precision measurement. > >> - Per-platform settings system is now image based. Allows to > enable/disable hardware acceleration, change default backends, change > font-mappings tables. > >> Some text examples: > >> (rendering) > >> <Mail Attachment.png> > >> (measurement) > >> <Mail Attachment.png> > >> Cheers, > >> Alex > > -- > www.tudorgirba.com > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > > > >
