Re: [css-pointer-events] proposal: opacity threshold (for easy hitmapping)

Hi Alex,

Understood, I was expecting the problem isn't easy to solve in WebKit. It
however isn't easy for us as well. We need to use canvas, use getImageData
and read out the alpha values. This fails if the graphics sit on a CDN
(same domain security issues). So it isn't even an option that works most
of the time.

The alternatives we've came up with (we needed to anyway, to possibly
support browsers without Canvas):

1. Vectorization (this is insanely hard, we would need to automatically
vectorize shapes into individual polygon outlines and then send to the
client)
2. Manual vectorization (generally easy, but a huge effort addition in the
asset pipeline for authors. Not a good option to us.)
3. Calculating the alpha hitmap at server level (huge traffic spike, as we
can only transfer this stuff with UTF-8 most likely. There's weird ways to
compress binary stuff in UTF-8, but decompressing will become the
bottleneck).

These are all very much half baked workarounds. Even though the way to the
API addition proposed might be stony and steep, it would be an immediate
win for so many developers.

Am 20.04.11 02:56 schrieb "Alex Danilo" unter <alex@abbra.com>:

>Hi Paul,
>
>	I can see this is an important use case.
>
>	However, the proposal as described is likely to be a big
>problem for browsers such as WebKit. The basic issue is where image
>decoding happens.
>
>	For example, WebKit has a bunch of ports to different back
>ends. On Mac/iThing etc. the images such as JPG/PNG are kept compressed
>in the in-memory model and the decompress and paint is delegated to
>the underlying graphics library which could optionally be H/W
>accelerated. So in essence the hit-testing code never actually
>sees the decoded PNG image - hit testing would normally be done
>on the known bounds of the object. So architecture-wise this would
>be a fairly non-trivial thing to implement at least for WebKit.
>
>	It would be good to hash out some alternate way this
>could be done to make the use case easier to handle. As it stands
>you would need to decompress all the PNGs just to perform the hit
>testing which will blow out memory usage and complicate things
>quite a bit.
>
>	If you used SVG for the hit testing, the authoring tool
>could trace a path around the PNG and place a transparent path
>object over the PNG to be the hit-testing target.
>
>Alex
>
>--Original Message--:
>>
>>Hi everyone,
>>
>>This is a proposal for a new value to the pointer-events property in
>>both SVG and CSS.
>>
>>It is seldom that games have overlapping functionality as most games are
>>very custom. Hitmaps is one of the functionalities that almost every
>>game that runs on the open web stack needs to support. It basically
>>describes that the player should be able to click "through" transparent
>>areas of objects. Take an isometric image of a house that is represented
>>as a png with some transparency around the edges. I want the click event
>>to only fire if the user clicks on a pixel that actually includes
>>visible content (the actual house).
>>
>>With current tools, and if you don't want to draw and manage every pixel
>>using canvas, this is a non-trivial problem. We have to create dynamic
>>hitmaps by writing the image resource into a canvas, reading out the
>>pixel data, saving it and then later use event delegation to map every
>>click to the right object. Therefore, I'm proposing to add syntax that
>>looks similar to the following:
>>
>>.house {
>>width: 200px;
>>height: 200px;
>>background-image: url(house.png);
>>pointer-events: opacity(60);
>>}
>>
>>This example would say "When hovering or clicking a pixel, check if the
>>computed alpha value is higher than 60 (either based on percentage or
>>0-255), and only in this case fire the event, otherwise delegate to the
>>element below".
>>
>>This amazingly simple API addition would make thousands of game
>>developers a lot happier, including Zynga. I realize this might not be
>>trivial to implement at the browser side, but I expect it will still be
>>easier and faster than me doing it in Canvas/JS.
>>
>>I'm eagerly awaiting your feedback!
>>
>>Thanks,
>>
>>Paul
>>CTO, Zynga Germany
>>
>>
>>
>

Received on Wednesday, 20 April 2011 10:04:41 UTC