Category Archives: newsletters

Bloc Update

Hello, this is my new update after two weeks.

Taking advantage of the VM release

The recent Pharo VM Release v9.0.21 for Windows, Mac and Linux was great for our Bloc project since we had some troubles with the graphic libraries dependencies. We take advantage in two aspects:

Simpler install instructions. Getting the project installed is now a simple script, as any other. Before, we had additional steps according to the OS platform (on Mac, via brew or macport; on Windows, by downloading dlls in a zip).

CI running again. The GitHub workflows have been broken some time. The reason was the difficulty to get the VM and update it with updated graphic libraries in the script. Happily, with the new VM release we have restored jobs in all three platforms. After fixing CI, some hidden bugs did pop up, such as an error when scanning fonts on Windows (fixed). Still not everything green, but it’s already good that CI is back!

Outskirts inside and outside

Some geometries now provide an explicit Cairo path to draw the border inside or outside, for two main reasons:

Rendering speed. A recent Bloc Update showed that rendering elements with border inside or outside was significantly slower than centered borders. Now, they are almost as fast as centered outskirts.

Dashed borders. There was a visual issue on elements with dashed border when the outskirts is not centered, i.e. inside or outside. Now it works:

Centered, inside and outside outskirts border

Closed issues on dashed borders:

For the moment, this improvement applies only for circle, rectangle and rounded rectangle, but will be extended to more geometries.

Gaussian shadow effect

In a nutshell, a general approach to create the shadow of a visual element is:
– take the alpha-channel of the element (an 8-bit image)
– apply an approximation of Gaussian blur on it
– paint the shadow color (with an offset), using as a mask the intermediate 8-bit image
– finally, paint the element on top of the shadow.
For example, SVG specifies the drop shadow filter like that. The big question was how to do Gaussian blur step, as Cairo doesn’t provide it out-of-the-box. The current solution is the adaptation of a linear algorithm (on the number of pixels) that looks good:

This element was created with:

BlElement new
	geometry: (BlRoundedRectangleGeometry cornerRadius: 50);
	size: 500@100;
	border: (BlBorder builder
			paint: Color blue;
			width: 15;
			dashArray: #(20);
			build);
	effect: (BlGaussianShadowEffect
  			color: Color orange
			width: 20
			offset: 20 asPoint);
	yourself

Warning

This implementation iterates over the pixels, all in CPU, which has its limitations. For example, on large and animated elements. If we implement some hardware accelerated alternative, this could be a solid fallback. However, in an element animation where only offset or color change, then caching the 8-bit image with the shadow mask should work very well.

Rendering regression tests

The following image gallery illustrates examples added to test regressions in rendering:

Binding for SVG and PDF Cairo surfaces

Our Cairo bindings in Alexandrie now support drawing to SVG and PDF files. Part of this code and tests are based on Athens implementation pushed to Pharo a couple of years ago.

A text with shadows exported to PDF using our Cairo bindings. Text is exported in vector-style, but shadow is a bitmap-style generated by our implementation previously mentioned.

Note: I exported this example using the Cairo bindings directly, without integration with Bloc. But it will be straightforward to integrate it.


Thanks for reading. Questions or feedback? Please refer to the #bloc channel at Pharo Discord server, or the lse-openbloc mailing list. Martín Dias

Tagged , ,

Bloc update

Hello, this is another report on my activity on the Bloc project.

Shadow Effect

Circle sectors with green shadows

This visual effect is quite common in graphical user interfaces, often to highlight certain elements or as a aesthetic decoration. When an element drops a shadow, it usually presents a darken and blurred-edges copy underneath. More in general, a shadow can have a x,y offset, an arbitrary color, and a Gaussian “radius” which can be zero meaning sharp edges.

We received requests to support shadows on the Alexandrie canvas and we have now a basic implementation, for the moment without blur. The first clear challenge was being fast on drawing the effect, however there were other challenges that I will comment briefly.

Open geometries and text

Straight lines, arcs and beziers can have a shadow, that on our first approach was working like on the right. This was following the Sparta-Cairo canvas implementation. But it didn’t look well so we changed it to be more like the SVG’s drop shadow effect (on the left side of the picture).

On text elements, we implemented it like on the picture. This also differs from how the other canvas behaves, casting a rectangular shadow.

Bordered elements with translucent or transparent background

The shadow of a completely opaque element, as on the left of this figure, looks fine as a uniform copy of it. When it is transparent as on the right, it’s clear that the shadow should take into account a border. However, the translucent background may be subject to discussion. We currently draw it as in the SVG specification, which is taking the alpha channel of the element that drops the shadow and uses it as a mask to paint the shadow color.

Border outskirts

Our Alexandrie canvas, on the left.

The border of a Bloc element may be drawn inside, center or outside of the geometry bounds. This parameter, named outskirt, required our consideration as the shadow should match the geometry extent with the appropriate border width and outskirt type.

The figure has a vertical line that separates two ways of drawing the shadow of elements. All hexagons have the same extent, only outskirts differ by column: The left column has outskirt inside, the center one has center outskirt, and the right column has outside outskirt.

Tests and benchmarks, and future work

All screen captures of this report are the output of new rendering tests. They cover a good number of combinations. Pixelated pictures ease comparation, and that’s why you may notice this characteristic on them.

There is a new benchmark for shadows, which shows performance issues that we are working on. Blurred shadow is work in progress.


Thanks for reading. Questions or feedback? Please refer to the #bloc channel at Pharo Discord server, or the openbloc mailing list.

Martín Dias

Tagged , ,

Bloc update

Hello, this is Martín in the weekly activity report on the Bloc project.

Animations

I did some code clean up and adding comments in the animations hierarchy, for example the class comment of the top superclass.

Pablo helped me to debug and fixed an issue on unexpected behavior on BlTransformAnimation. This was in the context of other reported issues like this one already mentioned in previous week update.

I profiled and added the first benchmarks on element animations. There are several candidates to optimize. Further analysis to be done.

Element effects

Bloc elements can have effects such as drop shadow. Our Alexandrie canvas is still missing to render effects. Should have news on next report!

FFI call logger

Along last year, we developed a small toolset to inspect Pharo FFI calls to better understand and improve performance in Bloc.

This week, I pushed some commits because:

The core of this project instruments a key method in TFSameThreadRunner to log each FFI call. This instrumentation is now done via a Reflectivity metalink, which seems to work very well. Before, this task was done via manually invoking it #compile: method.

About this project:

One of the tools traces the top called functions each second to the Transcript:

| #                 | calls/s |
|-------------------|---------|
| SDL_GetWindowSize |  647.35 |
| SDL_PollEvent     |  175.82 |
| SDL_GetModState   |   19.98 |
| SDL_RenderPresent |    5.99 |
| SDL_RenderCopy    |    5.99 |
| SDL_LockTexture   |    3.00 |
| SDL_UnlockTexture |    3.00 |
| SDL_GetMouseState |    2.00 |
| SDL_FreeCursor    |    1.00 |
| SDL_SetCursor     |    1.00 |
| SDL_CreateCursor  |    1.00 |

Other tool written in Spec2 allows more complex inspection and filtering:

Further information on project’s Wiki.


Thanks for reading. Martín

Tagged , ,

Bloc update

Hello! this is another update on activities the Bloc project.

Animations

Last week, I debugged an issue on Bloc animations, and discovered some issues more:

I’m in the middle of a change on the relevant package. This includes adding tests and comments, and cleaning up code.

Text rendering

Renames finished

Last week, I removed prim prefix from Cairo bindings methods, but Freetype and Harfbuzz were still missing. This is done now.

Debug combined emoji glyphs

We detected an issue rendering text with Zero-width joiner sequences. What is that? Fonts can specify a glyph for certain sequence of characters. This is the case of the following example, where the same Unicode sequence is rendered on first row using only Cairo, and the second row using Harfbuzz before Cairo:

The sequence can be generated in this way:

WideString streamContents: [ :stream |
    #( 16r1F468 16r1F469 16r1F467 16r1F466 ) "<-- individual faces"
        do: [ :each |  stream nextPut: (Unicode value: each) ]
        separatedBy: [ stream nextPut: Unicode zeroWidthSeparator ]]

The Noto Color Emoji font has a specific glyph for that sequence: the family shown in the second row of the screen capture. Without Harfbuzz to apply the font rule, we can only render the individual characters of the sequence (as in the first row of the capture).

The bug: Some times the family glyph is not rendered… that portion of the image is just white. Good news is that this is reproducible, not random. This example can be found in: AeHarfbuzzRenderExample class>>#example6Emoji, but should become a test.


Thanks for reading!

Regards, Martín

Tagged , ,

Bloc update

This is Martín Dias communicating the activity in the Bloc project in last two weeks.

Clipping nested elements

We detected and fixed an issue on rendering clipping nested elements on the Alexandrie canvas.

The following example shows the issue:

  • Each circle contains two children of half-size of the container
  • Green circles have clipChildren:true, red circles have clipChildren:false.

The output should look as on the right, but was actually rendering as on the left:

Clipping bug
Actual and expected rendering (left and right, respectively)

Improve test coverage

We already counted with AePixelMatchTest hierarchy to detect rendering regressions, but we needed to add tests for each combination of:

  • border outskirts (inside, center, outside)
  • background type (none, translucent, opaque)

A visual introduction to such combinations:

Outskirts and background examples
Three nested elements set up with multiple visual options. The larger circle has clipChildren:false, and contains a green circle with clipChildren:true, and contains the smaller red circle.

Draft performance analysis

After writing and running some benchmarks, we have a notion about these questions:

Did the above fix affect performance? A benchmark showed no change in general, BUT elements with Outside outskirt border with either transparent or translucent background did show a 20% slowdown (no change when background is opaque).

Does the chosen outskirt of an element affect animation performance? Yes, and it depends also on the background opacity. Centered outskirts are always the fastest. Next table shows the difference between Centered against other outskirts options:

There are ways to improve the bad performances of outside-outskirts border. One is taking into account each geometry and doing some simple math. Might explain better in another week update.

Pixel-match regression testing: an improvement

We already counted with AePixelMatchTest hierarchy to detect rendering regressions (or just changes), but had a weakness: if several forms had a regression, they were all detected in a single test failure (AePixelMatchTest>>testAllForms).

This is now reported as individual failures, inspired in ParametrizedTestCase, printing the “render” selector as suffix:

Graphics libraries: update VM, test and benchmark

As you may know, Pharo has FFI bindings to Freetype, Cairo (via Athens) and SDL (via OSWindow). Such bindings call dynamic libraries that are are files located on the filesystem. Bloc and the Alexandrie canvas use such library files. In general, such files are inside the PharoVM directory, but there not always:

  • The Mac VM provides dylibs for all of them.
  • The Win VM provides dlls
  • The Linux VM does provide a .so for SDL, but doesn’t for Freetype and Cairo. In such cases, Pharo looks at system’s shared libraries.

In particular, the Mac’s PharoVM comes with a set of graphics libraries that is too old. With an update, the performance speedup is awesome. The key library updates were:

  • Cairo: 1.15.4 -> 1.17.4
  • Freetype: 2.9.1 -> 2.12.1
  • SDL: 2.0.18 -> 2.24.1

Our goal is having the same library versions on all platforms. Pablo worked on the update for Windows VM, however versions are more recent there. On Linux, it depends on the distribution (as explained before). On Debian/Ubuntu, cairo is 1.16.0 and performance didn’t change that much in preliminar benchmarks. On Arch, it should be more recent.

Huge speedup on Mac

Next table shows the improvement in frames per second on 18 variations of a benchmark (see it at the end of the post). The only change between Old and New column is that the image was opened with VMs with outdated or updated library versions, respectivaly.

Graphic library update benchmarks

Each row of the table is a benchmark that on each frame draws 300 rounded rectangles, with a small square on top-left that may be clipped or not. They look like this:

Rename FFI binding methods

Before this commit, the convention for method names in Alexandrie’s FFI bindings was to always use a prim prefix. For example, the Cairo function cairo_matrix_invert was mapping as

AeCairoMatrix >>
primInvert
^ self ffiCall: #( AeCairoStatus cairo_matrix_invert ( self ) )


Now, this method is renamed as just invert.

We decided to use a distinctive prefix in selector only in certain cases. For example, for C functions that are typically used on instance creation, where the message sender has the responsibility to, at some point, call a free function to avoid a memory leak.

Fix rendering of annulus sector

Bloc counts with a BlAnnulusSectorGeometry, described as “I am a sector of an annulus. In mathematics, an annulus […] is a ring-shaped object, a region bounded by two concentric circles.” by its class-comment. An instance has a startAngle and endAngle to specify a sector. The meaning of the angles are:

  • An angle of 0.0 is in the direction of the positive X axis.
  • An angle of 90 degrees is in the direction of the positive Y axis.
  • Angles increase in the direction from the positive X axis toward the positive Y axis.

Visually, it can be presented like:

The issue: ambiguity in the meaning of the start and end angle

There is a difference in how Sparta-Cairo and Alexandrie canvas render this geometry. For example:

BlAnnulusSectorGeometry new
	startAngle: 180;
	endAngle: 120;
	innerRadius: 0.0;
	outerRadius: 1.0;
	yourself

is rendered either as a sector from 120º to 180º or as a sector from 180º to 120º:

This discrepancy is confusing for users. It was reported in this issue and the pull request is waiting for discussion / merge. Basically, we agree that the second option is the right one.


I hope that you liked this little report on the current activity to make Bloc working great.

Regards, Martín.

Tagged , ,

Pharo Newsletter May 2016

The big news of the month of course is that Pharo50 has been released! This is our most significant release yet. Here are some highlights:

  • The PharoVM is now based on Spur, the new memory management, and it brings with it a 35% speedup!
  • A new unified foreign function interface (UFFI) replaced.
  • …overall all 2400 issue tracker entries closed.

You can read the official announcement here:

http://pharo.org/news/pharo-5.0-released

Pharo Mooc

The Pharo Mooc saw a constant increase of participants with 2700 participants from more than 90 countries. It is entering its fourth week. More information
Pharo 6

With the stable release out, we have started a new development branch. As always, we slowed integrating changes while stabilizing the release, so this new development branch is seeing lots of changes that were held back.

As always, we do not ignore simple (even trivial) changes and have seen already many improvements related to typos, comments, cleanups… as well as some big-ticket items. One example here is support for immutable objects.

64bit Pharo: A Preview

The 64bit version of Pharo was able to run the whole image this week! Here is a screenshot:

8f398205-df62-4920-bd02-944282aff675.png

Sysmocom: Free Software for Mobile Communication

5faf528c-086b-4ab4-9bc0-b42d040726d2.jpg

Sysmocom is a leading provider of Free Software Mobile Communication solutions. In 2012 we have started a long term project to develop a complete ASN1, TCAP, MAP, CAP, GSM stack using the Pharo Object Environment. We have decided to use Pharo because of the increased productivity, the great tooling, the live inspection and if necessary modification of a running system to deploy a critical bugfix. Pharo has allowed us to focus on what is important.

The stack was used to uncover security and privacy issues inherent to the MAP protocol design in 2014/2015. We have used the stack to build a carrier-grade AuthenticationCenter (AuC) and helped a customer to move their production traffic off a proprietary system to ours. We look forward to move a HomeLocationRegister (HLR) into production this year.

Holger Freyther CEO. http://www.sysmocom.de

See http://www.pharo.org/success for more success stories.

Pharo Monthly Newsletter April 2016

Pharo Monthly Newsletter April 2016

The Pharo Community is busy preparing the release of Pharo5 for May. We got so busy that we forgot to send out a newsletter for March…

For this April Newsletter, we have three topics:

  1. The Pharo MOOC
  2.  Pharo Consortium: Membership Matching Campaign
  3. Pharo Days Report

To get Pharo related news every day, follow us on twitter @pharoproject.

Pharo MOOC
The Pharo MOOC is a new online course about Live Object Programming in Pharo.

The MOOC starts with over 2000 registrations on May 2nd. Register today!

Membership Matching Campaign
The Pharo Board is proud to announce a special campaign for attracting new Consortium Members during 2016.
A new fund has been created from which the Consortium will receive the equivalent of one yearly membership fee for every new member, and the increment in yearly fees for every upgrading member. For example, if a new company joins the Consortium as a Silver member (2000 EUR / year), the fund will contribute a one-time amount of 2000 EUR to the Consortium. Similarly, if a company upgrades from Bronze (1000 EUR / year) to Gold (4000 EUR / year), the fund will contribute a one-time amount of 3000 EUR.

This campaign will take place until the end of 2016, or until the fund is depleted. Currently, the fund totals 21000 EUR, a sum which is graciously supported by three companies: LabWare, Object Profile and Fenk.
http://pharo.org/news/membership-matching-campaign

Pharo Days
Pharo days were organised on Thursday March 31 & Friday April 1 in Namur (Belgium). It was a great moment to encounter other Pharo programmers, to feel community spirit, to discuss about the Pharo ecosystem and the improvment of the language, listen many interesting talks about various themas.

The schedule was interesting: We were lucky to listen talks about Seaside 3.2, data formats and protocols, Unified FFI, Bloc, Spur, etc. If you didn’t go to Namur, all the slides will be available on this website soon.

Many photographies and a video are already available on the web:

Thanks to the event organizers for their incredible work. The Pharo Days took place in a beautiful place (Le cercle de Wallonie).

Monthly Newsletter Feb 2016

Pharo Monthly Newsletter Feb 2016

We will start our monthly email to keep you in touch with the Pharo world.
You receive this mail because you subscribed at some point at http://pharo.org
In case of a mistake: there is link at the end of the mail to unsubscribe.Many things are happening as usual, far too many to list in one email.

The plan is to send one mail per month, never more, with just a selection of
all the things happening. (This one is late, it was for Feb 2016… there will
therefore be one more end of March)

If you are interested in all the news, there are blogs and twitter accounts to
follow. For example:

For a complete list, see http://pharo.org/blogs

Pharo 50 beta is getting well on track. We expect to have a release in Mid-April. We now have:

  •  Spur the new memory manager developed by Eliot Miranda.Spur includes new GC, new object representation, support for ephemerons, pinned objects and a lot more.
  •  new uFFI compatible with latest Spur memory manager.
  • new version of GT toolkit tools.
  • … and many great enhancements (break point, browser improvements,…)

To play with Pharo5, the latest development snapshot is available at http://pharo.org/download

PharoDays 2016: Two days at Namur to talk and exchange ideas about Pharo, see http://pharodays2016.pharo.org

More manpower: Pavel Krivanek, the creator of the Pharo mini image shrink, has joined on a one-year position to work on the bootsrap and other projects.

The Pharo consortium is growing, we are preparing an announcement for later this month. http://consortium.pharo.org