- From: Paul Bakaus <pbakaus@zynga.com>
- Date: Mon, 25 Apr 2011 02:44:27 -0700
- To: Paul Bakaus <pbakaus@zynga.com>, Alex Danilo <alex@abbra.com>
- CC: www-svg <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>, Doug Schepers <schepers@w3.org>, Simon Fraser <simon.fraser@apple.com>, Dean Jackson <dino@apple.com>
Bump. It seems Alex and Simon are in alignment that this is something we want, but hard to achieve. Honestly, I think "hard to achieve" isn't really an argument to let it go. If everyone agrees that it is desirable, can we just put it on the spec? That being said, I would like to have a couple more people participate in this discussion. I find this one of our most important internal problems, and it is weird that there is so little public interest. Maybe a blog post helps.. Am 20.04.11 12:01 schrieb "Paul Bakaus" unter <pbakaus@zynga.com>: >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 Monday, 25 April 2011 09:44:58 UTC