[deepamehta-devel] click detection

Jörg Richter jri at deepamehta.de
Di Okt 29 21:59:37 CET 2013


Hi Torsten,

please excuse the late reply.
(I know you were busy with other things anyway.)

As you might have noticed DM's new View Customization framework made considerable progress. A lot of aspects you covered in the recent postings are addressed by the framework already. Despite the framework is only in its first incarnation I feel it is quite potent already, and the design lays a good basis. I'm very happy about your recent input as it triggered a lot of fruitful action and results.

The Webclient's default CanvasRenderer and its extension mechanism is capable of both, Canvas based topic rendering and DOM based topic rendering. Related to Canvas topic rendering an extensible View layer is established above the viewmodel that holds all the data relevant for both, topic rendering and topic click detection. So the same calculations are not performed over and over. Generic click detection is implemented at framework-level.

But the real power comes from DOM based topic rendering. Because it exploits a lot of the browser's intrinsic capabilities like rendering, object click detection, event handling and propagation, viewport management and so on, it reduces the burden of the DM View Customizer developer tremendously. In contrast to implementing all the boring geometry calculations involved in Canvas based rendering implementing a DOM based View Customizer is real fun :-)

And that is what I like to share here, and what was all the result of the discussion you've invoked: Simulating movable and clickable Objects on a Canvas is kind of abusing the Canvas for things it is not made for. Of course you can deploy a Canvas-based toolkit which brings you all the nice object-oriented modes and interactions you need. In case of KineticJS (whose design and implementation is excellent!) this means 13.000 lines of JavaScript code resp. a footprint of 500KB to load, only to recreate a functionality which is already there, in every browser, for free: the DOM.
(Yet I'm sure there are a lot of cases for KineticJS).

There are 2 reference DM plugins that showcase the new View Customization framework:
	https://github.com/jri/dm4-box-renderer-canvas
	https://github.com/jri/dm4-box-renderer-dom
Both realize the very same look&feel -- the one you've originally proposed by the means of your screenshot -- one is Canvas based, the other is DOM based. The rendering heart of the DOM based version takes half as many lines of code as the Canvas based one, and its code is much more comfortable to read and maintain.

Torsten, I hope you'll like DM's new View Customization framework and the Box Renderer plugins and that we will bring them forward together.

Cheers,
Jörg


On Sep 24, 2013, at 10:31, Torsten Ziegler wrote:

> Hi Jörg and all GUI developers,
> 
> I am about to implement a new click detection for my renderer
> and seek for some advice, respectively am looking for a common
> ground of my development and the default renderer.
> 
> Right now the click detection in the functions
> find_topic_by_position and .._association_..
> implements "a a second drawing process"
> - all calculation is done over again on each mouse event
> - possible all but one objects on the canvas have to be examined
> - right now works only with rectangular bounding boxes of shapes
> (clicking on the "not painted corner" of the standard note ball will
> counted as click on the icon itself)
> - topics are always preferred over associations
> - topics first painted are preferred over the other ones in case of overlap
> (without repecting that visibility is the other way round)
> 
> What I would like to implement:
> - a lookup table to find the object without new calculations
> - non rectangular areas to reflect the transparent portions of an icon,
> or irregular shapes
> - allow for certain areas of one topic to react differently to the mouse interaction
> - allow more advanced detection of overlapped objects:
> -- certain objects might know that its not them to react but the lower one
> -- if unsure ask the user which one he/she tries to click
> (as it is just so nasty to move a topic accidently over another and
> suddenly you are not able to select it any more, but have to work your way
> through the selectable ones till you reach the one you would like to have selected
> in the beginning)
> 
> I see 2(3) ways to do this and here I would like your input:
> 
> 1. using a muldimensional array to keep track of all the objects and desired action on the canvas
> (object_canvas[x][y]=[{"id":id,"action":action},..] <- each point holds an array of one or many object ids and actions,
> empty points may be removed from the array ?speed vs. memory use?)
> - on drawing each object registers itself to this array (object_id + action(show detail pane, start association, bring to front etc.))
> - for unregular shapes or icons with alpha a helper function
> -- is provided with the smallest possible bounding box that includes the object
> -- does a bitmap compare of the canvas region bevore and after drawing
> -- calculates the visible parts that should be registered in the array
> - on a mouse event only the array has to be queried and all possible objects are directly accessible by lookup of their id
> 
> 2. using the KineticJS (http://kinetikjs.com)
> - implement the whole drawing and click detection using the kineticjs framework
> - pro: less code as drawing, caching, event handling is allready implented (using a second canvas for hit detection)
> - contra: overlapping objects are not supported, topmost rules
> 
> 3. wait till browsers implement the HTML5 HitRegion
> - this may take a while
> 
> Inspired by the KineticJS I would also like to look into caching of the objects,
> if this makes sense for the yet simple objects.
> It works the way that the object is drawn only once but then saved as an image that is
> drawn to the canvas later on.
> 
> What do you think?
> torsten
> 
> -- 
> Torsten Ziegler
> torsten at ziegi.de
> 
> _______________________________________________
> deepamehta-devel mailing list
> deepamehta-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/deepamehta-devel




Mehr Informationen über die Mailingliste devel