Support performant hit-testing

[GoogleCodeExporter]

Javascript provides the document.elementFromPoint(x,y) function to get a DOM 
element by position.
However, this requires 4ms in avg in my application and is inconvenient to 
implement [0].
I suppose using an exposed C++ API function would be more performant.

This issue has already been discussed here [1], but the performance did not 
matter.

[0] see attachment (mXXX variables are class members)
[1] https://code.google.com/p/chromiumembedded/issues/detail?id=319

Original issue reported on code.google.com by acm...@googlemail.com on 26 Oct 2014 at 3:34

Attachments:

• DOMHitTest.txt

[GoogleCodeExporter]

Some numbers.
Executions:     14818
average:    0.827 ms
min:        0.000 ms
max:        58.482 ms <<< !!!
0.1-quantile:   0.421 ms
0.25-quantile:  0.491 ms
median:     0.684 ms
0.75-quantile:  0.799 ms
0.9-quantile:   1.117 ms

Original comment by acm...@googlemail.com on 26 Oct 2014 at 4:09

[GoogleCodeExporter]

You say in issue 319:
> My application requires a hit test for every mouse movement.

What is your use case for this? Are you using the hit test information in the 
renderer process or communicating it to the browser process?

Original comment by magreenb...@gmail.com on 27 Oct 2014 at 5:54

[GoogleCodeExporter]

> What is your use case for this? Are you using the hit test information in the 
renderer process or communicating it to the browser process?

We use CEF as GUI for our computer game application by drawing a (transparent) 
webpage over some OpenGL stuff using offscreen rendering. To decide whether a 
mouse movement should be processed by CEF or not (e.g., the crosshair should 
not capture mouse movements...), we decided to flag DOM elements by a special 
class, i.e. "InputConsumer".
Then, we use hit-testing in the browser process to test if the DOM element the 
mouse is over is a "InputConsumer" or a child of such an DOM element.

So yes, we need hit-testing in our browser process. 

Original comment by acm...@googlemail.com on 27 Oct 2014 at 8:21

[GoogleCodeExporter]

@#3: DOM hit testing needs to occur in the renderer process. Even if C++ hit 
testing improves performance relative to JavaScript hit testing you still need 
to communicate the result from the renderer process to the browser process. 
That communication will introduce significant latency.

How complicated is your document model? You may be better off building your own 
parallel hit testing tree in the browser process and updating that tree when 
the DOM changes (using JS mutation events, OnScrollOffsetChanged, etc, to 
trigger the update).

Original comment by magreenb...@gmail.com on 27 Oct 2014 at 8:34

[GoogleCodeExporter]

Thank you for your fast response. That sounds like a reasonable solution.
We can implement a JS Mutation Observer (note that Mutation Events are 
deprecated[0]) in the renderer process that notifies the browser process if the 
DOM tree has changed (using IPC). Then we perform hit-testing with a local copy 
of the DOM tree. That should heavily reduce execution time. However, this will 
require some additionally afford (own functionality for hit-testing, because i 
assume using JS would lead to the same synch latency problem).
All in all, we can not make use of JS in a performant way and have to 
re-implement JS functions.

[0] https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events

Original comment by acm...@googlemail.com on 28 Oct 2014 at 10:00

[GoogleCodeExporter]

I think implementing a hit-test algorithm is non-trival.

Original comment by acm...@googlemail.com on 28 Oct 2014 at 10:04

[GoogleCodeExporter]

CEF is transitioning from Google Code to Bitbucket project hosting. If you 
would like to continue receiving notifications on this issue please add 
yourself as a Watcher at the new location: 
https://bitbucket.org/chromiumembedded/cef/issue/1416

Original comment by magreenb...@gmail.com on 14 Mar 2015 at 3:34