מסמך די היסטורי. תוצאה של מחקר וניסויים בתחילת 2011.

עם ההתבהרות שפלאש לא יהיה נוכח על גבי מערכת ההפעלה של הניידים של אפל, נתבקשתי לבדוק את המעשיות של יצירת סביבת משחק עשירה גרפית באמצעות טכנולוגיות דפדפן “טהורות”. בכנות, פלאש ואופיה הקנייני הסגור אינה נמנית עם הטכנולוגיות האהובות עלי, מה שהוסיף מוטיבציה להדגים שניתן לחיות גם בלעדיה..

עם זאת, פלאש של אדובי היא פלטפורמה מפותחת וגדולה, שאינה מסתפקת במתן פלטפורמת הרצה אחידה שאינה תלויה בדפדפן ומערכת הפעלה, אלא גם סביבת פיתוח עשירה שמקשה מאוד על מציאת אלטרנטיבה ראויה.

כתוצאה, החיפוש הטכנולוגי היווה נסיון לפשר בין הצורך לתמוך במספר גדול ככל האפשר של פלטפורמות הרצה, לבין הרצון להרכיב אוסף כלים וסביבת פיתוח ראויה ונוחה לעבודה.

תחילה, עלינו להגדיר את הפלטפורמות בהן אנו מעונינים לתמוך. זוהי רשימתנו ההתחלתית:

• אקספלורר 9+
• פירפוקס 3.6+
• אופרה 11
• כרום
• ספארי
• iOS מובייל ספארי תחת
• דפדפני וובקיט תחת אנדרויד

כמו כן, ישנו הצורך ליצור תהליך עבודה נח עם הגרפיקה שאנשי הקריאטיב יוצרים.

כרגע, אין אלטרנטיבות ראויות לסביבת האנימציה והתסרוט של פלאש, שמאפשרת להגדיר קוי זמן של אנימציה, לנהל מבנה אובייקטים, ונותנת אינטגרציה יפה עם האילוסטרטור וכלים אחרים של מעצבים.

מרגע שהדרנו רגלינו מהשבילים הבדוקים והידועים שבין חבילות מסחריות, האחריות להגדיר את תהליכי יצוא הגרפיקה מן המעצב על התמכנת עוברת אלינו.

תחילה, בדקנו את SVG כשפה עילית

.

There are no ripe alternatives to the Flash scripting environment, which allows scripting animation timelines, managing a scene graph, and seamless integration with Illustrator and other tools that artists use to create artwork.

Once off the treaded commercial toolchain path we are on our own to define the export process of graphics from the artist to the front end programmer.

Initially, SVG was examined as a high level language. SVG seemingly has the following advantages:

• Relatively high-level - has its own traversable DOM, to which events can be attached
• Supports complex animation primitives such as animation along a path, shape morphing
• Resolution agnostic (Vector Graphics)
• Posession of something inherently similar to a scene graph
• can use SVG as a native format when importing artwork

With such a list of advantages, one could think that this technology is ideal for our needs. However, the following offsets and undermines these:

• Implementations of SVG vary across browsers in features support
• On some platforms it is quite slow
• the SVG DOM and API was discovered to be complex and hard to use for truly dynamic scenes where objects are instantiated and thrown away.

So it was decided to try a level lower approach with Canvas, and use an abstraction library on top such as Processing.JS

• Canvas is a simple standard and hence almost universally supported on modern browsers.
• Processing gives a degree of abstraction that Canvas lacks as well as an ability to import SVG
• with Canvas we get very fine grained (literally, per-pixel) control over the viewport

Implementing an initial test scene in Canvas/Processing revealed that many primitives that inherently exist in SVG had to be implemented, such as:

• Animation along a path
• Object Mouseover/click detection
• Shape morphing, being complex to implement algorithmically, was done via an Inkscape plugin and exported as a frameset for sprite animation.

These shortcomings would all still be acceptable if in return we got consistent cross platform behaviour that we control to the pixel. Thus, it was decided to proceed with a more real-life example. Unfortunately, this new demo exposed a show stopper for the Canvas/Processing duo: terribly low FPS using Canvas on MobileSafari.

Attempts were made to optimize the demo by removing the background redraw, reducing the amount of objects on screen, removing object textures, all with unsatisfactory results.

By this point, having spent a good deal of time unsucesfully trying to achieve a seemingly straightforward goal forced a rethinking of the methodology. The weakest link in the chain is obviously iOS & other slow-CPU mobile platforms.

On these devices, fast graphics are achievable only with the help of native hardware acceleration. And it seems that in MobileSafari, only the HTML DOM gets that treat.

So the last blackjack table demo was re-written again, this time using HTML & CSS3, this time with sound and some transparency effects.. and - Success! As an immediate result, MobileSafari performance improved.

After further reading and specialized optimizations, the framerate was made very smooth. In iOS 4.x MobileSafari is only partially accelerated, and careful choice of DOM manipulation methodology is needed to squeeze the most out of this browser.

Personally, I was surprised to have been capable of achieving all of the requirements of a graphically intensive scene with “just” CSS transformations and HTML. While busy looking for a silver bullet in the form of an advanced technology, the bread and butter of web programming went unnoticed until other options were exhausted.

This is not to say that Canvas & SVG do not have their place. But with the above realistic goals, SVG is more suitable for complex but rather static diagrams, and Canvas simply doesn’t pull it on the current generation of Apple mobile devices, leaving the scene for just one tech: CSS3.

Incidentally, our choice, dictated by the platform’s low common denominator, forced us to iron out our own custom artwork digestion & montage process. But that’s subject for another article..

The code examples found in this article are available for download off the writer’s GitHub account:

• https://github.com/guyromm/svg-test - initial SVG test
• https://github.com/guyromm/processing-test - initial Canvas/Processing test
• https://github.com/guyromm/processing-casino-test - BlackJack table demo, Processing (table.html) & CSS3 (table2.html).

article tags:

games,flash,css3,svg,canvas,processing,processing.js,browser,web,html5,javascript,webkit,mobilesafari,ios,apple