Re: [whatwg] Typed numeric 'input'
2014-08-04 20:06, Christoph Päper wrote: Imagine a text layout GUI made with HTML. > It would probably feature a font size selection control. There are different ways to do such a thing: There are, and they are preferred in different ways by different people, as programmers or as end users. This is why any solution, in addition to introducing considerable complexity into HTML, would be used for a small fraction of potential use cases only. An addition to the ways mentioned, the font size control could be simply two buttons, one for increasing and one for decreasing the size, possibly with keyboard shortcuts and possibly a button and/or shortcut for resetting the size to the default. And many others. As I’m said, I’m not sure what’s the best solution, but HTML should have a typed numeric input element with conversion capabilities. The designer needs to decide the internal representation of the font size and to map the alternatives in the UI to that. I don’t see how additions to HTML would significantly help here, even if they happened to match the approach that is selected by the designer. Yucca
Re: [whatwg] Question on server side api
On Aug 4, 2014 7:08 PM, "L2L 2L" wrote: > > ... Here's a question that will get a huh? > > Do the browser have an api that is use This is a stupid question Do the browser have an api that I can use to preform --I'm still a novice-- simple server side action? No. Browsers have no control over your server beyond sending requests for content and hoping the server responds. To do anything server-side, you want to learn a server-side language, like Node.js, PHP, or frankly anything, as long as you can find a framework you like. ~TJ
[whatwg] Question on server side api
... Here's a question that will get a huh? Do the browser have an api that is use This is a stupid question Do the browser have an api that I can use to preform --I'm still a novice-- simple server side action? E-S4L
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
Many, many uses of drawImage involve transform and/or other state changes per-blit (composite mode, global alpha). I think some of those state changes could be viably batched for most games (composite mode) but others absolutely cannot (global alpha, transform). I see that you handle transform with source-rectangle-and-transform (nice!) but you do not currently handle the others. I'd suggest that this needs to at least handle globalAlpha. Replacing the overloading with individual named methods is something I'm also in favor of. I think it would be ideal if the format-enum argument were not there so that it's easier to feature-detect what formats are available (for example, if globalAlpha data is added later instead of in the '1.0' version of this feature). I get the impression that ordering is implicit for this call - the batch's drawing operations occur in exact order. It might be worthwhile to have a way to indicate to the implementation that you don't care about order, so that it is free to rearrange the draw operations by image and reduce state changes. Doing that in userspace js is made difficult since you can't easily do efficient table lookup for images. if rgba multiplication were to make it into canvas2d sometime in the next decade, that would nicely replace globalAlpha as a per-draw value. This is an analogue to per-vertex colors in 3d graphics and is used in virtually every hardware-accelerated 2d game out there, whether to tint characters when drawing text, fade things in and out, or flash the screen various colors. That would be another reason to make feature detection easier. Would it be possible to sneak rgba multiplication in under the guise of this feature? ;) Without it, I'm forced to use WebGL and reduce compatibility just for something relatively trivial on the implementer's side. (I should note that from what I've heard, Direct2D actually makes this hard to implement. On the bright side there's a workaround for RGBA multiplication based on generating per-channel bitmaps from the source bitmap (k, r/g/b), then blending them source-over/add/add/add. drawImageBatch would improve perf for the r/g/b part of it, so it's still an improvement. On Mon, Aug 4, 2014 at 3:39 PM, Robert O'Callahan wrote: > It looks reasonable to me. > > How do these calls interact with globalAlpha etc? You talk about > decomposing them to individual drawImage calls; does that mean each image > draw is treated as a separate composite operation? > > Currently you have to choose between using a single image or passing an > array with one element per image-draw. It seems to me it would be more > flexible to always pass an array but allow the parameters array to refer to > an image by index. Did you consider that approach? > > Rob > -- > oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo > owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo > osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo > owohooo > osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o > oioso > oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo > owohooo > osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro > ooofo > otohoeo ofoioroeo ooofo ohoeololo.
Re: [whatwg] [2D Canvas] Proposal: batch variants of drawImage
It looks reasonable to me. How do these calls interact with globalAlpha etc? You talk about decomposing them to individual drawImage calls; does that mean each image draw is treated as a separate composite operation? Currently you have to choose between using a single image or passing an array with one element per image-draw. It seems to me it would be more flexible to always pass an array but allow the parameters array to refer to an image by index. Did you consider that approach? Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
[whatwg] [2D Canvas] Proposal: batch variants of drawImage
Greetings all, In a drive to satisfy some the most demanding performance critical applications--2d platformer games--, browser vendors have put a lot of effort into optimizing CanvasRenderingContext2D, and the drawImage method in particular. In a world where browsers have GPU-accelerated graphics backends and complex multi-threaded rendering frameworks, the ultimate hurdle in relieving computational burden from the browser's main thread is: per draw call overhead. In a sprite based animation, the application may be calling drawImage hundreds or even thousands of times per animation frame. The script bindings and browser internal bookkeeping that is performed on a per draw call basis is a O(N) cost that could be made O(1) by introducing batch versions of drawImage. Benchmark experiments performed using Chrome on mobile and desktop platforms show that this is currently the main obstacle standing in the way of achieving near-native rendering performance. Here is what I am proposing: http://wiki.whatwg.org/wiki/Canvas_Batch_drawImage Feedback wanted. Cheers, -Justin Novosad
[whatwg] Typed numeric 'input'
Imagine a text layout GUI made with HTML. It would probably feature a font size selection control. There are different ways to do such a thing: 1 2 3 4 ptpxmm There are, of course, more possible units and one might want to supply a ‘datalist’ with suggested predefined values, e.g. Most desktop word processor GUIs use something like option 2, by the way, some always expect points and hence only provide solution 1 or just a drop-down list of predefined values. It’s not possible, however, at least as far as I know, to strongly associate the two controls in options 3 and 4 (i.e. for number and unit) with each other, so UAs could employ a native widget for typed values. When the user changes the unit, such a widget could either keep the numeric value or convert it accordingly. This is what I’d like to propose, but am not sure yet how. Although it makes sense to store value and unit together and convert on demand, they are more often converted into a purely numeric format, which usually will result in rounding errors (e.g. all those A4 PDFs that claim a page size of close to but not exactly 210 mm × 297 mm) unless a very small base unit is chosen. For length units used with font sizes, this might be EMU, half-point, twentieth-point etc. – let’s assume EMUs with 12700 emu/pt and 36 emu/µm. Since TeX uses the classic pica point (0.166 in/pc) instead of the simple DTP point (12 pc/in) the above ‘datalist’ would look like this (if striving for unnecessary precision) But how could the accompanied ‘input’ support multiple views (i.e. conversions) onto this unified representation, and without exposing it to the user? The first solution I came up with is a ‘units’ attribute as follows: The HTML4 fallback, however, would be horrible, because users would be exposed to EMU, which they absolutely must not be. Therefore one of the units would have to be selected as a default. This could be done with a more verbose, but reusable ‘datalist’ instead: ‘units’ could also be called ‘scale’. If, however, we would prefer a variant with 2 form elements that may be joined (option 3, 4) instead of a single complex one (based on 2) as shown above, we’d need a way of associating them with each other. These lack a possibility to specify conversion factors. That might be achieved by As I’m said, I’m not sure what’s the best solution, but HTML should have a typed numeric input element with conversion capabilities.
