[Bloc] Hierarchy of BiEvent

Denis Kudriashov wrote

BlKeyModifiers encode smart boolean flags about keys back into integer bits

Hi Glenn. Thank's for answer.

2016-10-26 13:29 GMT+02:00 Glenn Cavarlé <[hidden email]>:

More generally, i think that, to stay consistent, Bloc should not reuse
directly (and everywhere) some part of underlying libraries even if sometime
these parts seems to match directly.

I can't take it. Duplication is always bad. There is no reason for it.

I think we just don't need OSEvent's.

Real low level is SDL events hierarchy.

And OSSDL2WindowHandle built OSEvent's from them:

OSSDL2WindowHandle>>handleNewSDLEvent: sdlEvent

^ sdlEvent accept: self

But we can delegate this processing to osWindow

osWindow handleNewSDLEvent: sdlEvent

which then will call eventsHandler of given window.

And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level. 

Denis Kudriashov wrote

I can't take it. Duplication is always bad. There is no reason for it.

Denis Kudriashov wrote

And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level

stepharo wrote

> OSWindow cannot be the only one backend for Bloc so Bloc events cannot be
> based on OSEvents.
Why that?

stepharo wrote

I do not get why on android we cannot map android event to OSWindowEvents
And do not have duplication in Bloc.

stepharo wrote

So then it means that OSWindowEvents are not useful.
But to me this is bloc events that are not needed.

stepharo wrote

> OSWindow is already used in other projects and these users will not be happy
> if we remove OSEvents ;).
who?

Denis Kudriashov wrote

2016-10-26 18:21 GMT+02:00 Denis Kudriashov <[hidden email]>:

> No. You are not right here. Conversion code for OSEvent=>BlEvent and
> SDLEvent=>OSEvent is almost same. All events have similar interface to
> retrieve event data.


I mean conversion code in both cases is just stupid creation of new event
classes on top of state of original events. No logic behind.
(all logic to parse raw bytes are hidden inside sdl-events)

2016-10-26 19:45 GMT+02:00 Glenn Cavarlé <[hidden email]>:

Yes, your are right.
What i mean is that it could be interesting if:
[ SDLEvent => BlEvent ]   is substantially faster than   [ SDLEvent =>
OSEvent => BlEvent ].
If the difference is not significant, i think that does not justify to not
benefit from OSWindow abstractions even if sometime they bring nothing more.

If you already thought about Announcements performance and produce optimized alternative then I think it is critical to get events fast.

Now we have 10 variables which are decoded from int by bit operations:

leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd rightCmd capsLock numLock

And then Bloc encodes them back to int. So for any event we have 20 operations and it is not just primitive calls. 

Also OSEvent creation produces own garbage for internal structures which also take time and memory.

But for me most important is how maintain both hierarchies. You answer Stef that nothing will change over events during years (nobody invent new one or not often).

But such argument could never be valid. Code is used, it could has bugs, it could be improved by itself. People will always need to work with this code, at least to read it. And it is difficult with two hierarchies which are managed by double dispatch. Try to follow how concrete BlEvent is produced.

And there is already some problem. I investigated deeply what happens in sdl about modifiers and buttons. It is not easy. But I see that some information becomes lost.

And Bloc also not provides full information from original objects (modifiers and buttons). 

So to fix these issues one needs to modify both hierarchies. First he needs to decide how decode modifiers from SDL and then how to encode them into Bloc bits.

And I am sure new issues will be found again and again. It is normal process.

Le 26/10/16 à 20:40, Denis Kudriashov a écrit :

2016-10-26 19:45 GMT+02:00 Glenn Cavarlé <[hidden email]>:

Yes, your are right.
What i mean is that it could be interesting if:
[ SDLEvent => BlEvent ]   is substantially faster than   [ SDLEvent =>
OSEvent => BlEvent ].
If the difference is not significant, i think that does not justify to not
benefit from OSWindow abstractions even if sometime they bring nothing more.

If you already thought about Announcements performance and produce optimized alternative then I think it is critical to get events fast.

Now we have 10 variables which are decoded from int by bit operations:

leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd rightCmd capsLock numLock

And then Bloc encodes them back to int. So for any event we have 20 operations and it is not just primitive calls. 

Also OSEvent creation produces own garbage for internal structures which also take time and memory.

But for me most important is how maintain both hierarchies. You answer Stef that nothing will change over events during years (nobody invent new one or not often).

But such argument could never be valid. Code is used, it could has bugs, it could be improved by itself. People will always need to work with this code, at least to read it. And it is difficult with two hierarchies which are managed by double dispatch. Try to follow how concrete BlEvent is produced.

And there is already some problem. I investigated deeply what happens in sdl about modifiers and buttons. It is not easy. But I see that some information becomes lost.

And Bloc also not provides full information from original objects (modifiers and buttons). 

So to fix these issues one needs to modify both hierarchies. First he needs to decide how decode modifiers from SDL and then how to encode them into Bloc bits.

And I am sure new issues will be found again and again. It is normal process.

So denis you suggest that Bloc uses directly SDLEvents.
This would make sense from your analysis.