On 1 March 2017 at 05:42, Alexander Samoylovich <samoylovich@gmail.com> wrote:
Thanks everybody for the explanation.

I tried to apply Igor's suggestion. I allocate an offscreen surface 1 row larger than needed��
and when converting discard one row.

The code looks more stable now. The test was up for about 30 minutes before crashing instead of 1 minute before the fix.
Is it the right code change or just a coincidence?��
��

AthensCairoSurface>>asForm


"create a form and copy an image data there"

self checkSession.

self flush.

^ Form extent: (self width@self height) - (0@1) depth: 32 bits: id



no, it isn't . This is how it supposed to be there.
But the problem is when you using surfaces for bitmaps in Cairo itself,
you're screwed since AthensCairoSurface purposedly makes it 1 row taller,
while for texture you want it to contain exact height, else you'll obviously have artifacts. :(

So, the point is: if you creating a surface that will be used by bitblt (asForm), then you should allocate 1 extra row,
else you shouldn't.. And there's no workaround to match such behavior in single class,
since it doesn't knows what it will be used for :(
��

On Mon, Feb 27, 2017 at 2:39 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

On Mon, Feb 27, 2017 at 7:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
and i was dealing with it by adding 1 extra line to cairo surface,��
but reporting 1 less to Form. Like so, bitblt still reads past the
allowed size, but it is safe, because there are unused bit(s).

On 27 February 2017 at 20:31, Igor Stasenko <siguctua@gmail.com> wrote:


On 27 February 2017 at 12:29, Esteban Lorenzano <estebanlm@gmail.com> wrote:
Hi,

the problem wit Ronie���s fix is that (as he says) you are copying another time the surface, before passing it to the VM (who makes yet-another-copy) so this is not optimal��� and you can see it when running the Tiger demo: there are a lot of pauses.
So I would prefer the other approach he suggests:

Form subclass: #AthensCairoSurfaceForm
�� �� �� �� instanceVariableNames: 'surface'
�� �� �� �� classVariableNames: ''
�� �� �� �� package: 'Athens-Cairo'

AthensCairoSurfaceForm>>surface
�� �� �� �� ^ surface

AthensCairoSurfaceForm>>surface: anObject
�� �� �� �� surface := anObject

AthensCairoSurface>>asForm
�� �� �� �� "create a form and copy an image data there"
�� �� �� �� self checkSession.
�� �� �� �� self flush.
�� �� �� �� ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 bits: id)
�� �� �� �� �� �� �� �� surface: self;
�� �� �� �� �� �� �� �� yourself

that seems to work. Can you try and see?


Btw, remember the culprit there , that you must have extra word in trailing buffer space,
this is because bit-blt using read-ahead . Which is OK for objects located in object memory,
since there are always something past the last object (unallocated space),
but not so ok for buffers allocated by malloc (such as cairo surface bitmap), and so,
if you read even a single byte past it, you get protection fault.
��
Esteban

> On 24 Feb 2017, at 15:47, stepharong <stepharong@free.fr> wrote:
>
> Hi alex
>
> can you try the fix of ronie and let us know if it makes roassal more stable?
>
> Stef
>
>> Dear Alexander,
>>
>> Sine the new FFI of Pharo, using Athens has become unreliable. This is a pity, but fixing this is not trivial at all (we have been trying for years).
>>
>> What exactly are you doing with Athens?
>>
>> Alexandre
>>
>>
>>> On Feb 22, 2017, at 12:55 AM, Alexander Samoylovich <samoylovich@gmail.com> wrote:
>>>
>>> Hello
>>>
>>> I am writing graphic demo programs using Athens on Mac Sierra.
>>> Time by time Pharo VM crashes. Programs not using Athens work reliably.
>>> I believe the behavior is reproducible.
>>> How should I report a bug?
>>>
>>> Alex
>>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>





--
Best regards,
Igor Stasenko.



--
Best regards,
Igor Stasenko.





--
Best regards,
Igor Stasenko.