Thursday, December 20, 2012

Images embedding into HTML

Currently known image use in HTML do not have a support of reusing:
  • IMG tag do not refetch the file, but still issues http request
  • CSS background-image keeps the image in backround. Still it is the most powerful since it allows to reuse the image, pick the tiles, associate with CSS rule switch animation.
  • SVG embedding allow to reuse the image only by reusing its source text. Each image will have own instance in browser.
JS has a powerful gears for image reusing. The cloning image node will keep the same image reference. Unfortunately this optimization did not sneaked into JS libraries I am using.

Q. How to make image reusing convenient and still efficient on browser side?

Will be the preprocessor of HTML template the proper answer?
  1. It could strip off the URLs from IMG tags. Say by renaming src attribute.
  2. Load the image say in hidden node, keep it in global url to img map
  3. Upon image load and when widget dom is ready, roll over all IMG-es in DOM and swap with clone of cached one; apply all original attributes and CSS.
This method should work as compiler layer + runtime patch to DTK templated widgets;

PS. This note is just a response on multiple attempts around on image use optimization. As plain idea it is not worth anything, so bug me if you see the need for code or help there.

Wednesday, December 5, 2012


Usually asserts are not destructive. I.e. even if condition false-d, the code still working. Your evaluations throw-ing exceptions and changing the logic. Also there is a some additional logic resides in assert call:
  • in release build the code is disabled, ideally removed by compiler
  • log output with caller function
  • log evaluated value
  • log comment string
  • breakpoint call
Extra things I do in C++ and could potentially port to JS:
  • modal dialog with assert info(above)
  • ability to ignore further( do not display dialog), retry(repeat the condition call)
  • counter for particular assert failures
  • log not just to comsole but also to external target like FS or server.
There are some related patterns applied in debug mode
  • automatic parameters and return value check against type and permitted values. That should have the type definition and values/validators be available in run-time. Used Annotation for that. The call traps need enumeration of object's methods and wrapping by aspect.
  • Profiler( call counts+timing, call graph, etc) is not a hot topic anymore since most of browsers have them implemented. But in many cases like mobile, it worth to have the profiler be implemented by JS and hooked into server-side logger.
Final assert call I envision as such:

while( assert && assert( isDomNode(param1), "should be a valid dom node") );

or simpler form:

assert && assert( isDomNode(param1), "should be a valid dom node");

assert && assert(...) gives ability to disable assert for release build on AMD module switch level. It also could be used for individual module tuning.
while( assert(...) ) needed for "Retry" option. Handy for debugging. When problem found, the same condition could be reevaluated for step-through debugging.

Annotations and aspects are the gears for such functionality. 25% of above I have done earlier but not made a shippable tool. It is too big effort to be justified by projects I was working on at the time. If anyone interested we could talk further.

Wednesday, July 18, 2012

Use of dynamic css as HTML5 game play engine

CSS transforms are neat and powerful effects engine in HTML. Besides of HTML it could be used for SVG graphics on same page.
And what has been only web page with SVG became serious gaming platform.
For JS developer it would be straight to implement most of gameplay and scene control using JS+canvas leaving some effects to CSS.

But when a kid asked me to help with building the game, functional/aspect programming appeared to be easier. It is quite simple to explain that by adding class name to character's dom node its appearance and behavior changed accordingly.
To add little attraction to this approach, CSS-driven effects are way more efficient than same with JS. Less CPU, easier development.
Not to mention more reliable code: no memory leaks, JS closures, etc.

Obviously CSS is not much designed to change the DOM, hence the gameplay could not be completely covered by this approach (see disclaimer on active CSS)
So what are the layers and what benefits to chose technology for each?
1. DOM as model
For simple arcade the visual and business object model have a 1:1 match. In this case there is no need to separate game and UI objects. Implemented as DOM subtree character or scene will be able to preserve and manipulate own data utilizing as JS as native browser capabilities.
  • Having screen coordinates matching the game scene will fuse native rendering, motion and colorspace/transparency/fog/shadow effects supported by browser.
  • Zoom could be applied by changing the default font size and defining the model in em units. To make it even more attractive, the focus subscene or object could have dynamic font-size allowing to zoon-in or grow the character without affecting other model parts. Achievable by class name.
  • DOM subtree as scene component/character. It is hard to enumerate what adwantages could be gained. Some of them:
    • Design and develop as independent module (HTML, CSS, transformations, behavior). From HTML space SVG for vector graphics, GIF animation(see disclaimer), etc.
    • Event-driven interaction. Native declaration and handling. Native events( mouse, swipe,etc) support along with no model parameters conversion( this is reference to node which is same as in UI as in model, model coordinates == screen coordinates). Event propagation interface and handling.
    • Ow, forgot about tons of docs and help on HTML and CSS.

2. Behavior definition.
Primarily defines reaction of the system and its parts on various kinds of events. Literally event-driven engine.
There are multiple implementations I could think of. At the moment could not make any preference.

  • JS. By picking the library with artificial + native event support and transform/effect most of the needs are covered. Other features are depend of project complexity and personal view. Such things as modularity, compilation, documentation, etc. really could be skipped.
    JS itself is not oriented for the task and only libraries could give enough abstraction for event-driven behavior definition.
  • Event definition and transformations chaining is native part of SVG. While the language is not perfect itself, it gives native (read most efficient) support and prevents such mistakes as hanging event chain(when broken in the middle of execution), memory leaks, object and timing conflicts. Need to check cross-browser capabilities.
3. Support and low-level functionality.
Many app sides like saving to database, communication with server(s) belong to "support" or "service" layer. So far I see only 1 choice: JS. Better with sufficient featureset library. DTK for example.

The game is not only about visual interaction but also about sound. Not just background music but rather interactive and event-driven. While HTML5 has support for such, it is possible to utilize multiple sound player widgets with events and sound level control.
Unlike visual the sound sources count need to be more limited to avoid unrecognizable mash-up. The proper join of sound source with associated scene component(s) and ability to switch the vocal focus requires separate implementation of sound players stack and visual game model.

Voice or/and video communication creates another dimension for gameplay. Those have own set of requirements and definitely should be dedicated in own layer. Quite often dominating for resources consumption. This part is not necessary need to be embedded into game scene. For resources distribution reasons it worth to keep it even in separate frame or even window. Multiple monitors are not exception novadays.

Active CSS assumes to associate behavioral patterns with class names. Some browsers have sufficient support for such( lovely HTC, or poor Mozilla ones), but there is no good unified native cross-browser solution.
This gap has been closed by approach on JS level, but in this case we have poor JS performance. Being purist on my own, I do not see the benefit for gameplay logic completely covered by CSS class names manipulation.
3D rendering and stereo. Unfortunately it is somewhere in the future for cross-browser development. But if you have in mind customized WebKit(?) environment, than many principles of this article could be applied now.
GIF animation. While it seems familiar and simple solution, it is quite inefficient in terms of control and resources. On one side it is raster graphics and needs pre-scale(saved in larger than usual use dimensions) to support acceptable quality. On another side consolidation of GIFs into single tiles file seems to be heavy for resources and should have synch animation effect. Never tried thought :) Alternatives with SVG transform- or CSS-transform driven animations given way more control and flexibility along with smaller memory and CPU footprint. Forgot to mention "skinning" of characters which is difficult to achieve in GIF and so easy by SVG. Skinning is applying for same element coloring by team, incremental details upgrade, etc. The goal should be skinning control by the node class name changing as most memory(same node and image) and CPU(native transformations) saving .

Happy coding!

Saturday, April 28, 2012

HTML5 strict for Dojo Toolkit pages and templates

While there are many opinions on whether to use HTML5 , strict, XML syntax, etc. I would like to highlight my own reasons.


  • entry page to have most cross-browser compatible (with predictable behavior) mode.
  • widgets templates to have most strict syntax enforced as by HTML validator as by functional and visual tests.
  • widgets templates to be tested against different doctypes and modes to support SDK requirement of customizing and extending UI by user.


First 2 requirements are orthogonal to each other and have different outcomes Primary landing pages should have
  • doctype as in HTML5
  • html with XHTML namespace
  • lang attribute( to be mirrored by metadata tag )
Do NOT include the processing instructions for XHTML.
<!DOCTYPE html>
 <meta charset="UTF-8" />
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Widget templates

For each modulle template XHTML 1.1 is more suitable due to higher standard compliance reasons.

This DTD is equal to XHTML 1.0 Strict, but allows you to add modules (for example to provide ruby support for East-Asian languages). Note that processing instruction INCLUDES XHTML DTD

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "">


Input appreciated.