Yes. At this point, there is no fallback implemented. Doru
> On Oct 23, 2016, at 10:43 AM, stepharo <steph...@free.fr> wrote: > > Doru > > does it mean that right now with Sparta we do not have any fallback? > > Stef > > > Le 21/10/16 à 15:41, Tudor Girba a écrit : >> 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? >> >> But, now my question: Would it not be possible to get the VM to not open a >> window when in headless mode? >> >> 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." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Beauty is where we see it."
