Preserved Topic: Javascript animation performance: video hardware-related? (Page 1 of 1)

Hey guys,

I've been busy and haven't been around for a bit - for reference, I can finally talk about the stuff I've been working on. Here's a guest view of some of my work (The photos, and the site too of course!)

http://new.photos.yahoo.com/idliketowork/

(Think desktop selection model; grab some photos, drag and drop, etc. We're working on numerous bugs, plans to improve performance under Safari and Opera in particular.)

This link will expire some time after June/July, just FYI.

Anyways, I've been doing more fiddling around with Javascript animation stuff, and seem to have noticed a pattern between video/graphics hardware acceleration and performance in Firefox on the PC. Can someone confirm this or offer some other insight?

Below is a post I made to the "ydn-javascript" Yahoo! Groups e-mailing list just earlier this morning - thought I'd re-post it here given I know some of the local crazies might have some additional insight.

- Scott

- - - - - forwarded message below - - - - -

This is more generic and not implementation-specific, but I think it's an interesting topic, and I'd be interested in hearing of any others' findings/experience in the area.

From some of the more recent work I've done, I've seen some pretty interesting correlations between javascript animation performance (render speed / frame rate / CPU use) and graphics cards on the PC with Firefox in particular.

IE appears to be able to take advantage of ActiveX and/or rendering hardware acceleration which results in lower CPU use and higher frame rates when doing javascript animation, even on older computers or graphics cards. In my particular cases, I'm animating multiple elements at the same time and also applying both PNG and CSS-based opacity effects.

Firefox does not perform as well as IE nicely on a computer with an older or onboard graphics card (CPU use is higher / frame rate is lower,) but I've noticed it can be as fast as IE when using a newer, slightly higher-performance graphics card on machines with even slower CPUs.

I'm not exactly sure how it all works, but it would make logical sense that the graphics card handles rendering and redraw of elements where possible (particularly transparency/opacity effects,) and where hardware acceleration is not possible on the graphics card itself, the work is offloaded to the CPU - presumably much less efficient - and therefore slower.

From what I've seen, onboard/"integrated" graphics cards on typical desktop set-ups such as the Intel 82865G don't perform very well in this regard, so animation in Firefox is slower / requires more CPU in these cases.

On my computer at work (A 2.8 GHz P4 with onboard Intel 82865G graphics), IE has no problems with JS animation for most cases; Firefox doing the same work however is noticeably slower. I have seen several 1.6 GHz laptops with nicer graphics cards, which ran the same JS effects smoothly also in Firefox despite having much slower CPUs (eg. a 1.6 GHz with non-onboard graphics runs faster than a 2.8 GHz with onboard, in Firefox.) This seems to be indicative of some video or other hardware acceleration going on.

It should be noted that I can run the same effects quite smoothly on an old 866-MHz Pentium III with IE, and again Firefox is slower (also, this system has an old/integrated graphics card - I would imagine with a faster card, I would see similar performance gains.) Several years ago, my old Celeron 433 with onboard graphics would run a Javascript version of "Arkanoid" perfectly smoothly in IE, but Firefox would run slower.

Unfortunately most common desktops may not have graphics cards that would enable this kind of performance gain under Firefox; at this point I'm not exactly sure what, if any, hardware feature makes this all happen.

For what it's worth, I've spent a fair bit of time playing around with animation and performance experiments on previous personal projects, some more general findings are noted on my site.
http://www.schillmania.com/content/projects/javascript-animation-2/

- Scott

- - - - - /forwarded message - - - - -

quote:

---

IE appears to be able to take advantage of ActiveX and/or rendering hardware acceleration which results in lower CPU use and higher frame rates when doing javascript animation, even on older computers or graphics cards. In my particular cases, I'm animating multiple elements at the same time and also applying both PNG and CSS-based opacity effects.

---

Ah, interesting questions Made the same observation a few years ago when changing pcs.
While it doesn't make sense in terms of software design, it may make a lot of sense in real world.

MS have been a part of the original ARB (OpenGL Architecture Review Board).
They left it when DirectX came out, or the other way round.
They've been known for investigating the capacities of gpu for anything... including database processing!
And if you look at your registry, or used MS style filters at some point, you probably noticed that part of the core Windows classes
provide access to DirectX filters.

So, who knows? But everything hints at that.

Design wise, it's weird: the thing with graphic cards is that they are meant for a very specific task.
Actually, they work as a pipeline in all possible ways: send your input (native) calls on the ubber fast AGP bus, the card processes through it's rendering pipeline,
and returns the final set of pixels.

But these don't have to be pixels, it's not necessary: 24 bits per each can express a lot of things.

Due to the high video games market demand, those gpus have, indeed, evolved towards monstruous capactities.
Once you know how to use OpenGL or DirectX, it just a daily amazement to see you can add more and more and more options,
effects, more complex calculations without - ever - reaching the limits. (therefore, it is also easy to get lost,
and make crappy effects that indeed bloat up the cpu, but as long as you do it correctly, it just seems to never dry out).

It's a weird feeling I get recently: while I know what I can ask a CPU, which is more or less defined, although those have tremendous capacities already,
I still have no idea of what are the current limits of gpus. Not to mention what they will become in a year or two.

I am about certain of one thing though: only very, very few people are able to picture those limits.

I've noticed the same thing when running scripts on old and new comps after upgrading and I think it would make sense.
We can use DirectX to apply filters on images for transparency and other effects (PNG fix for example), so why couldn't the browser use DirectX internally too? If MS finds an error in their rendering routines, and most programs use the same methods, they just need to apply the fix in one place. And it lets all programs use the same set of routines so no duplicates are needed.

Anyway, I just watched a guy play a game utilizing a Physics card (ppu? lol) today at DreamHack. I wonder what other things it could be used for.... JS ragdolls anyone? :P

/TwoD

Physics card? Just wondering... a bit of a "too broad topic" to sum it in one architecture or is it just me? Dunno..

http://www.ageia.com/physx/index.html
Sorry for taking it OT, but you've got to see it if you haven't already.

/TwoD

Oh my God! I wish the concept catches up, because it would be a revolution indeed.

I am digging deep into the windows api lately, and am understanding the cpp "basics" of true "Windows programming"
(until now, was rather using c or cpp in a generic way with console apps, or os independent pre-made apis like OpenGl and glut),
eg, windows specific programming.

It's as much a pain in the backend as the OS itself.

The only thing I can say which, agains, hints at the gpu, is that when using GDI, aka graphic device (interface I guess?),
you'll proceed this way, more or less:

* setup and create rendering context, for painting
* setup and create window and window process

Windows (the windows api as it stands in a winxp 2 - have non-MS dev environment and probably old interfaces at hand, but anyway..) explicitely allows me to create an OpenGL enabled painting context, among types.

Windows are laid out as different, interdependent sub-contexts, aka components (ui widgets).

So... would I be a Windows cpp purist, if I hade to render complex html/css pages, it would make sense to render them offscreen on the gpu,
for max performances and per pixel precision in 16M colors.

...If I was to develop a portable browser like FF, big Open Source thing that has to compile easilly on as many platforms as possible, it wouldn't make sense to use the same facilities, because they vary greatly among OS's (leading to forks in code and unstable, heterogenous, *weaker* programs).

Same for Opera, but Opera chose to rely partly on existing IExplore structures though (apparently).

----------------------

Oops, better late than never.
I actually notice this for IE, not FF Go figure. Scott's question is the other way round.

(Edited by _Mauro on 06-20-2006 21:39)

..amend, and the answer:
http://weblogs.mozillazine.org/roc/archives/2005/04/glimpse_of_the.html
Which is also confirmed on the gecko page:
http://www.mozilla.org/newlayout/overview.html

No, Mozilla doesn't use the underlying hardware as of today, will do as of version 2.0.

But in my experience, IE seems to do it. My 2 cents..

Ah-ha! So it sounds like Firefox and Opera do not currently take advantage of hardware acceleration due to their cross-platform requirements? I would agree that generally makes sense, given that they probably don't want to have too much custom code within each distribution (though I'd imagine there's a certain amount of that regardless.)

But wait, are you saying that IE does use the GPU for rendering? (I would think it does, given it's windows' "native" browser and not cross-platform, etc.?)

From what I've found, Opera still seems to be pretty fast in terms of JS animation - it wouldn't surprise me that it can use some existing IE stuff.

Quoting from the link you posted:

quote:

---

On Windows, we will try to use OpenGL, but if that doesn't work well we could implement a Cairo backend using D3D. The non-accelerated Cairo renderer will be based on GDI. Owen Taylor and others are already working on that.

---

I'm not terribly familiar with graphics acceleration methods, but either way it sounds like they're looking at acceleration that is not currently in Firefox.

(Edit) It should be noted though that I have seen significant performance improvements just by having an accelerated 3D card on a laptop (JS animation, moving multiple objects with alpha opacity effects) - as mentioned originally - so there is definitely some sort of performance gain with 3D hardware in current versions of Firefox, even if they aren't doing anything specific themselves.

Also re: Opera 9, I have found it to be quite slow with the new Yahoo! Photos site (and there are some other bugs I'm working on) - performance is quite slow when dragging photos around for some reason, I need to do more investigation.. it might relate to the PNG-based alpha opacity effects I'm applying, but again I'm not certain. It's unusual because in my past findings, Opera has been amazingly fast in most cases.

(Edited by Scott on 06-21-2006 16:56)

Exact. Somehow weird though... for accelerared gfx, OpenGL, the standard, is cross-platform, 100%, as long as
there is a video driver for the backend which is still an issue on Linux.

For Windows and IE, I feel the rendering is performed on the hardware, at least in parts.
Much easier for the reasons you quoted.

Overall, I wonder what's "heavier" in terms of computations for web pages rendering: is is the sole "display",
blitting of pixels to the screen? Is it, instead, the parsing/layout stage?

Mysteries, as far as I am concerned (layout and the gecko engine seem to be big, but how does that relate to the rest? Dunno). Liorean? Poi? God?

From one of the links above:

quote:

---

...so that SVG effects can be applied to HTML content.

---

Oh, that makes me drool!
I'm always looking for ways to get closer to the hardware with JS, this might be one step closer...

/TwoD

Like you I think IE, and Safari, are more prone to benefit of the HW as they are closed source and made by the company that make the OS. I honestly don't know exactly how Firefox and Opera render the pages. It wouldn't surprise me if they do everything in software in some back buffers and blit the result ( or parts of it in the case of partial redraws ) to the surface of the window/tab. All the more that the core of Gecko and Presto are the same on various OS/platforms ( including mobile phones and video game consoles ).



As for getting closer to the HW, guys, let me tease you a bit with 3D Canvas. It's been implemented last summer in an internal build of Opera. I made the 3D snake game in 2 days though I knew nothing about 3D Canvas. I'm looking forward to see what Vladimir Vuicevic came up with and how we could write an open standard together.

[EDIT] NB: the TRON-esque style in the screenshots is a personnal choice. I could have made/used any kind of texture. [/EDIT]



(Edited by poi on 06-22-2006 01:14)

Uh-oh, just re-read what may be an edit... missed it the first time, my bad or not.

quote:

---

there is definitely some sort of performance gain with 3D hardware in current versions of Firefox, even if they aren't doing anything specific themselves.

---

Well, as poi said, that one definitely does not make a lot of sense given that:
- Firefox makers say they don't use the hw as of today.
- The windowing sub-system of OS's like Windows doesn't use the hardware either -aside specific cases.

Not wanting to disappoint you, but while there may be another, convoluted explanation, a couple of machines are not enough to be *sure* there is a software cause to this.
Mine is a laptop with a radeon 9600 and FF sucks balls compared to how it performs on my main, desktop P4 (newly equipped with a sexy 20" and also has a radeon inside).

In other words: the gfx card is a straight pipeline, a very powerful one, which takes 3d data as an input and spits out pixel data.
If you don't explicitely setup a software canvas for it, and call it, it sits there, and that's it.

FF makes report they don't use it.

And Windows per se doesn't use it, although specific apps can (like IE).

Plus, the Opera behavior you observe doesn't occur on my laptop, it's fast in display and page access.

Go figure? I really recommend more tests on broadly different hardware, the track and topic are interesting.

Further to this discussion, I would like to add that I think Safari on OSX has the potential to be a lot faster than it is (and should be, given it's the equivalent of IE on windows, the OS' "flagship" browser.) For whatever reason(s), DOM performance and Javascript animation are nowhere near as fast as they could (read: should) be.

In my findings, an 800 Mhz Pentium III runs JS animation effects faster in IE than a dual 2 GHz Mac with OSX; the mac chokes easily. "Static" rendering seems to be pretty good, but DOM changes including animation and so on really seem to be inefficient with Safari.

I have heard that Safari is still using the "Quartz" system for rendering, which may have something to do with its sluggishness?

Safari, Firefox and Opera on the Mac all seem slower in DOM/JS animation performance than their equivalents (in the latter two cases, I mean) on Windows. It frustrates me as a developer, because I'm trying to build really cool stuff that's fast on cross-platform browsers on Windows - shouldn't it be similar on the Mac and other platforms with the same browsers? Do browser developers spend less time optimizing (or have less ability to optimize) on/for platforms other than Windows? Does MS make it easy to tie into hardware acceleration, etc.?

Maybe it has something to do with how MS treats memory?
In windows apps they tend to use more memory if it allows them to keep things close at hand and do things quicker, rather than going for low memory usage.
But maybe the Mac doesn't allow them to do the same thing? (I wouldn't know since I don't touch Macs unless in a Black Mesa hazard suit. )
The other browsers wouldn't have the same problems though...

/TwoD

There are inner diferences, core stuff, in OS's. Unix/Linux like OS's treat multitasking/multithreading "better" than Windows, in that Windows tends
to put "more weight" (it's difficult to explain in details, it'a matter of threading model) on a given process depending on wether it is in use or not,
while things like OSx and KDE rely on operating systems that share cpu time more evenly.

About OSX and memory, it tends to be more powerful than Windows in terms of mem management, my guess would be that mem access on Macs
and Linux/Unix based systems runs like a charm. The way the application handles this is something different altogether.

In general, Mac products are more "academically perfect" than Windows / MS, which tend to behave more "commercialy", all talk, less guts.
This means they tend to "do things right": multithreading deserves it's name, mem management deserves it's name, etc.


Scott, one way to explore these undocumented areas... this is what "good hacking" is all about btw, is the quirksmode method:
try and benchmark all different options for a given CORE action you want to perform. If your thing is instanciating new dom nodes,
test all possible ways to do it, to delete those nodes, etc.

Benchmark it upside down: some things have really unpredictable behaviors in scripting languages.

Find the quirk that works for you, there -has- to be one.

............

For example, for Safari, I'd test "Konqueror" as well, and would compare, in different OS's.

Don't know about Quarz though.
Actually, the Safari makers homepage states it's faster than all other browsers on the Mac From developers, in general, this means
they have seen and tested it at those speeds... in a given, test environment

Something to look into.

Actually, the specs say Safari does use Quarz, which shouldn't be an issue: in theory, it's the opposite, it should be an advantage.

http://www.apple.com/macosx/techspecs/

?-| Is this a known Quarz bug? If not, I suggest you check your gpu or gpu drivers or something on that side.

_Mauro,

Some good points. However, I still find that the Mac seems to be just consistently slower in general for JS animation, not specifically to a particular site or method.

Interestingly, my old portfolio site runs fairly quickly in Safari even on my Mac (An 800 MHz PowerPC G4, 512 MB, ATI All-In-Wonder card) despite its relative age and not-great graphics card. It should be noted that the site does slow down when the "windows" on my site grow near the size of the screen, but I am running a 24" widescreen LCD (1920x1200) which presumably also affects the graphics card's performance. Nonetheless, I think the performance is OK here because my site is pretty simple in terms of content and layout - the containers are absolutely-positioned, there's no alpha transparency etc.

Those seemingly-popular "lightbox" viewers might be a good general test of animation capability given they use a large semi-opaque element, resizing elements with solid background colours and so on, but again you'd have to judge "by sight" - they don't provide a "frames per second" sort of measurement.

My DHTML Arkanoid remake from 2002, though not perfect, is quite playable in Firefox on the Mac - unfortunately due to a dynamic <script> JS loading bug, it's broken (probably the only thing, d'oh!) and currently doens't work in safari, but I'd imagine the performance would be similar.

Given some of my older stuff works quite well, I'm wondering what has changed between those times and what I've been doing more recently. The first thing that comes to mind is "layout complexity" - quite literally, the number of relatively-positioned, floated and clearing elements that are now used with more modern layouts.

I have noticed instances where Firefox will break down in animation performance (See this Firefox bug I filed related to "absolute moving over many floated elements in the same parent container", a regression in 1.5 that did not exist in <=1.0.7,) .. So I wonder if perhaps the browsers in some cases are also just literally being "loaded down" with rendering work due to elements being moved around. Redraw/reflow of the document, I mean. I would be interested to see if Safari has some sort of profiling tools available in this area.

I'm talking specifically about the new Yahoo! Photos, where you can select and drag a number of photos (try mine) - when you start dragging, clones of the thumbnails are created and appended to a top-level, absolute DIV which should isolate them from affecting the redraw of other elements, at least as far as "siblings" are concerned (aside from the elements being moved, this "drag-drop container" is empty.) As an experiment I might try simplifying the layout or removing floats/other positioning, to see if the frame rate goes up on the Mac. We have a fix for the Firefox issue, but it results in some other goofiness due to absolutely-positioning an element on the body.

I am almost certain Firefox (at least, on the PC) is affected by graphics hardware, as I have seen a laptop with a 1.6 GHz CPU outperform my 2.8 GHz desktop in terms of animation frame rate on the new Photos site, the differentiator I believe is the graphics card (I've got onboard Intel graphics here, the laptop had an nvidia medium-end "gaming" card I believe.)

Given the performance issue I've seen with Firefox though (and we are applying a workaround for Firefox in fact, which fixes the issue,) I'm now wondering more about the Mac. Some things are fast, but others aren't - it's a bit of a mystery, since you have to really poke around, try to find patterns. Welcome to the wonderful world of web development, I guess.

Compatibility is a very real issue in all aspects of software development, especially Java and C/Cpp (in CPP, you can choose -any- api, and take the portability route,
or the platform specific benefits).

But
>> I am almost certain Firefox (at least, on the PC) is affected by graphics hardware
Does not match the specs.

And for Safari, it also is the other way round: I am not saying what you say is not true, I am saying I can't reproduce the exact same bugs for some reason
(different encoding, different drivers, different hardware, you name it). I am also saying they could not directly relate to the gpu usage (but to some specificity of motherboards
which support recent gpus, for instance? Many options here too).

I am also saying how OSX differs from Windows fundamentally: since both are the OS, platform specific code is built on top of them (and is impacted positively or negatively by theyre inner workings).

All in all, gpu usage may not be the holy grail of web pages rendering (or it may be): the whole process is so complex, and that's maybe my main point,
that it should be fully benchmarked and analysed to find the cause.

It should be analysed in terms of complexity, theorical and practical: is blitting (gpu job) the most complex part? Is dom analysis the most complex part? how are these steps subdivided? Where is the real bottleneck, and what does differ internally in different browsers? Many, many, many things methinks.


It's not as if there were 50 types of memories, but there are gazillions of possible ways to do things on different OS's.

A couple of design certainties: somewhere, there is a paintable/drawable component which is the browser Window,
and such a component exists on all browsers.

There is a lexical/syntaxic analysis of the js itself.
There are the same things for css and html.
There is an association of the resulting outputs, and a dynamic one at that.
All these take in account potential quirks, which will result in different drawing modes.
There is an event handling system.
There is asynchroneous communication with web servers.

All these activities relate in a way or another to the sole page display in a browser.

...since Moz compiles on all platforms in pretty much the same way, and is very portable itself, I guess it uses "adaptive" mechanisms for each platform.
On each windowing subsystem, it will need a graphic device context to draw anything, so it will probably "acquire" a platform dependent one and translate it
into something usable internally.

These all are simple pointers, because the full analysis would take ages and immense efforts, but they give "google directions".
On Windows, for example, GDI is one of the things that allows getting a graphic device context, does it provide an accelerated context when available?
Not that I know off, unless it is specified.

Hell, since FF is Open Source, let's have a look...

http://lxr.mozilla.org/mozilla/source/gfx/src/windows

That's what I was looking for. No import of anything but standard libs and the windows api, no import <gl/gl.h>, so no direct use of the gpu.
In all of the source files.

They mainly "map" FF drawing function to GDI, aka Windows drawing functions.
Now, if we look into GDI details:
http://blogs.msdn.com/greg_schechter/archive/2006/05/02/588934.aspx

We can see one possible, remote explanation to the problem you describe:
GDI images being double-buffered, they *could* benefit a responsive gpu in the cases described on that page - and only in those particular cases.
But this is "casual" hardware acceleration rather than a real DirectX/OpenGL full usage.

Another possible explanation: high-end up gpus provide high resolution timining mechanisms (down to the nanosecond instead of millisecond),
which could impact the rendering system used by Mozilla. The source linked above treats images as animated things, and therefore whacks a timer in.

Too low the timing resolution can lead to bad "threading" and other concurrency issues (setTimeout could be impacted rather than anything else).

But still, the source code of FF appears to only expose GDI, normal Windows images so far.
(...then why the hell does Safari underperform on Macs? Since that one DOES use accelerated images. The bottleneck may be somewhere else for that one...)

Time for a cup of coffee.

Let's not forget that PCI-E or AGP 10.000x graphic cards have a much bigger bandwidth ( and thus fillrate ) than an average or built-in card, not to mention a card for which the proper/latest driver is not installed. You don't need to use HW acceleration to benefit from the high bandwidth of mid/hi-end graphic cards.

Heck, I installed my new computer few days ago. It has a beast of a graphic card a.k.a. GeForce 7950 GX2. Before installing the driver, moving a windows was sluggish. With the driver I only managed to get it slow down a bit with a really intensive demo in 1280x1024 with 16x AO filtering and basically everything to max quality.

I even found some more info on the question of double-buffered graphics.
Diggig deeper in the Firefox specific builds, I found this article:
http://www.forum4designers.com/archive89-2005-6-254834.html

The are usages of DirectDraw in the code, but they're turned off for the public builds.
Some moz community programmers even report it wouldn't improve things to use a hw buffer... doh?

As I was saying, gpu doesn't work well for all graphics tasks.

From the discussion linked above, the FF behavior you describe seems to boil down to a double-buffering issue that I don't care to understand.
A matter of swapping data from a crippled backbuffer to a frontbuffer, bad swap routines I guess.

For Safari, the discussion above also sheds some light: some approaches seem to require passing data back from the video mem to the system memory,
which loses the speed gained during the drawing process.

@po1, feels good to have some processing power, uh? I am considering an Nvidia too, just because I own two OGL2.0 compliant ATI gpus already
Those recent graphic units are monsters.

---------------

This whole issue shows how important engineering is: gpus ARE monsters, but it depends on how you use them.

Things like Vista or Mac OS X more advanced version will end up fully rewritten to rely mostly on the gpu for system graphics, and use appropriate buses
and memory technologies, but for now, it doesn't seem easy to have a gui mixed with an OS and hardware graphics.

Interesting findings. I think there are some profiling tools for Mozilla stuff which can help you determine where the browser is spending its time in the render process, this might be worth digging into if it's a common problem.

On a related note, I filed a bug late last year with Mozilla over a javascript animation performance degradation issue. (Detail here.) It appears that a combination of relative containers with nested absolute and floated elements is much slower to redraw/refresh under Firefox 1.5+, where Firefox 1.0.7 was much faster by comparison.

Apparently it is related to a combination of relative and absolute elements and the clearing of floated siblings/child elements, quote: "the patch for that bug made messing with the abs pos kids of a rel pos block reflow all of its in-flow kids; not doing that screwed up clear in some cases." - so it appears if you change one element (ie. animation,) all sibling nodes are now reflowed? (Highly expensive!)

The abs/clear issue was fixed in 1.5, but caused this performance regression. An example is given also.

This affects a rather large site I'm working on () and I suspect it may be an issue for other sites with more-complex layouts, so I'm hoping to get some more people looking at the problem.

(Edited by Scott on 08-09-2006 20:12)

Ideas, ideas, ideas, good company, and a cup of coffee.
Aaaaaahhaaaaaa that's life... thanks for starting this.

Request to Mad-Scis: is it possible to archive this thread directly without sinking it?

Would be cool. We're in a goldmine right here and right now, thanks to Scott questionning
"those *obvious* things"

_Mauro: Thanks - rendering performance and JS animation stuff have been areas of interest of mine for a while. I'd love to see the day when we can do effortless 3D transformations, animation and DirectX/Core Animation-style image effects across all browsers - I suppose I can dream, right?

As an update on the bug I filed re: performance - it sounds like this is issue which may be looked at in upcoming "reflow refactoring" work, which as I understand covers general rendering performance (how the browser does layout/drawing) and so on.

Even though this isn't down to the browser code level or anything, it's pretty interesting just reading about the theory of how the browser handles drawing of boxes and so on. Definitely a "niche", special interest area and not something your typical web developer type would be looking into!

quote:

---

image effects across all browsers - I suppose I can dream, right?

---

Well, what has become obvious to me through recent security concerns is that Windows hadn't evolved much until .net.
Everything before that is Windows 95 being debugged, that's all.

I mean: 0 "redesign" took place, or almost, as far as the lower level apis and overall structure was concerned.
Leaving bugs from 95 to be fixed in 2006. Some still haven't, tipycally, what are known as "system messages" can't really be secured in a "pre-vista" architecture
(one can use them to do many things from live programs hijacking, keyloggers, privilege elevation, etc..)

Vista will be the first revision really trying to "match" the hardware and software, and design methods evolution through these years. Mac OSX, somehow, preceeded it, and XGL for Linux.

Once the structure of all major OS really reflects current hardware, your dream may become true.



(Edited by _Mauro on 08-26-2006 15:13)