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 <[email protected]> wrote:



On Thu, Oct 20, 2016 at 9:07 AM, Aliaksei Syrel <[email protected]> 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" <[email protected]> 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."








Reply via email to