[Vm-dev] BUG? A problem with callbacks that shows up in 64bits (but is on 32bits too)

[Igor Stasenko]

On 14 March 2017 at 20:47, Bert Freudenberg <bert at freudenbergs.de> wrote:

>
> On Sun, Mar 12, 2017 at 4:53 AM, Esteban Lorenzano <estebanlm at gmail.com>
> wrote:
>
>>
>> Hi,
>>
>> this is lockSurfaceFn:
>>
>> createLockSurfaceFn
>> ^ FFICallback
>> signature: #(void * (void *handle, int *pitch, int x, int y, int w, int
>> h))
>> block: [ :handle :pitch :x :y :w :h |
>> pitch signedLongAt: 1 put: (self get_stride: handle).
>> self get_data: handle ]
>>
>> and
>>
>> createUnlockSurfaceFn
>> ^ FFICallback
>> signature: #(int (void *handle, int x, int y, int w, int h))
>> block: [ :handle :x :y :w :h | 0 "Do nothing” ]
>>
>> cheers!
>> Esteban
>>
>
>
> Just as an aside: I think in lockSurface you might want to do a
> cairo_surface_flush before accessing the data. Otherwise Cairo might still
> be accessing the bits while they get moved around by the GC - not a good
> idea. And unlockSurface should use cairo_surface_mark_dirty_rectangle.
>

IMO this should be done at another level, i.e. in AthensSurface>>#asForm,
it makes sure to do flush before answering an instance of Form, that using
cairo surface as its bits.
In other scenario(s), if user keeps drawing on surface, even after he used
#asForm , then it should be his own responsibility to do a #flush at proper
point.
I am not a fan of implicit behavior, because it is a source of confusion
and extra code runs that can be avoided, when user knows how to do things
right.
The rationale behind it, is that flushing rendering pipeline can take
unknown amount of time, depending on scene complexity, current state of
context etc, etc,
and if one wants , say a stable framerate, he should be able to manually
control all the flush points, else he won't be able to do it.


>
> See RomePlugin>>showSurface:x:y:w:h: and unlockSurface:x:y:w:h: (
> http://www.squeaksource.com/Rome.html)
>
> - Bert -
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170315/03847291/attachment.html>