Topic awaiting preservation: Question regarding IMG manipulation

When manipulating the physical dimensions of an IMG, performance significantly decreases. Back in the good old days, you would utilise binary boundaries to optimise these tasks, such as divisible by 64, 32 etc, so that bitwise operations could be employed for efficiency. I have not been able to dis/prove this with anything under DHTML, so does anyone have some suggestions for optimal IMG dimensions (apart from "as small as possible").
Does any rendering engine perform better with certain tile/bob sizes, or could this be dependant on the graphics driver / card on the client even?

Hi,
Some of my dhtml games resize multiple images during gameplay. I have found that IE performance is really good with resizing images. Its fast and it doesn't seem to matter how good the graphics card is--it always works well.

Mozilla on the other hand requires a good graphics card to keep the speed up. The games I've written slow to a crawl in mozilla whenever image resizing is taking place.

Brent.

BRENT SILBY
www.def-logic.com
Neo-Arcade Videogames

What I was after was info regarding relative benefits of the dimensions of the original image. Is there any benefit if they were rounded off to certain dimesions?

I`m probably the last person here to defend mozilla when it comes to performance

I doubt it. Bitwise optimizations really only worked on certain CPU's and even then it was simply taking the load off the CPU by reducing the amount of multiplication or division operations it had to do. Nowadays, with processors commonly over the 1Ghz mark, doing a multiplication or division instead of a bitshif isn't likely to cause anything noticable unless you're doing it more than several million times a second.

The slow DHTML/Image performance isn't likely to be affected by this. With Javascript, you're talking to the browser's APIs. All of the drawing and rendering would be wrapped up in sever layers of code, most of which is probably streamlined to render text documents. Creating images at specific sizes isn't likely to even make a dint in the performance.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

InI: Sorry, but Dracusis's point was extremely clear and I have to second him. He strictly spoke about the impact of bitshifting over divisions and multiplication. With todays ( and even few years old ) processors, and seeing the amount of layers between our JavaScript codes and their final execution in machine code, using either a bit shifting or a division is unlikely to make any difference.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

InI: I don't want to piss you, nor start another useless flame-war, but nobody else but you talked aboud JAVA. Afaik Ray Norrish only talked about DHTML in his initial post, and posted it in the DHTML/Javascript forum.

However if you still want to argue about optimization in JAVA, you can start a thread in the Server-Side Scripting - Oh my! folder subtitled "CGI & Perl, PHP, Java & JSP pages, SSI & XSSI, ATG Dynamo, Broadvision, Vignette or (you choose!)".

[edit] I don't want to pollute that legitimate thread anymore, so please InI, if you want to continue this, do it by email. [/edit]



(Edited by poi on 09-24-2004 13:34)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Oh dear. Actually, this has gone way off point. I was after info regarding specific benefits of the source IMG dimensions when performing resize operations (so only the way the rendering engine handles this is relevant).
I would also say that I can confirm that bitshifting DOES make a difference (I have severely optimised routines this way) but that wasn't what I was originally asking about.

Without the benefit of seeing the actual machine code which is responsible here, it could be anything. However, if the standard calculus appears to be optimal when shifting, it would be beneficial if IMG source images did as well.

I would have to say that an intepreter that saw 16>>2 decided to calculate that as 16/4 would be crazy, similarly, if was building a rendering system, I would be looking for the same thing - even if it was only for a portion of the image?

quote:

---

poi said:

InI: Sorry, but Dracusis's point was extremely clear and I have to second him. He strictly spoke about the impact of bitshifting over divisions and multiplication. With todays ( and even few years old ) processors, and seeing the amount of layers between our JavaScript codes and their final execution in machine code, using either a bit shifting or a division is unlikely to make any difference.

---

poi: I have to comment here - Because of most of the stuff I`ve been doing lately, I`m converting demos from Amiga - which were designed and written to be super optimised (the amiga stuff, not mine) 16 pixel wide this, 256 pixel high that because of the way the amiga blitter worked etc.. the translation of which allows me to use bit operations all the time. Indeed, If you don't try a complex routine with shifted and non-shifted computations and you don't see a difference - I`ll eat my hat! (or at the very least bite it very hard!)

Of course, this could just be IE.. but I`m convinced that there is tangible improvement.

quote:

---

InI said:

Just contacted my C++ teacher who seconded me on the fact it does make a difference,waiting for a benchmark In C, though, it greatly depends on the compileras it would using javascript depending on the interpreter, but there is a large difference anyway.

---

Perhaps the point is that given modern CPU speeds there is no visible difference. I agree that there will be a difference, because its bit shifting rather than division. However the difference wouldn't be detectable unless you are going through millions of such operations.

Brent

BRENT SILBY
www.def-logic.com
Neo-Arcade Videogames

For the point described by Dracusis, that is doing simple divisions and multiplications, the results are really close except for one case : the / vs >> in Mozilla. Here is the little sample code I've ran :

loopCount=262144

	a = 198798

	while( loopCount-- )

		// operation ( pick one in the comments below )



//  operation   |  the timing below are the average ( in ms ) of 50 executions of the script above

//------------------------------------------------------------

//  b = a<<7    |  mz173 = 404  | ff09 =  395  | ie50 = 181  |

//  b = a*128   |  mz173 = 411  | ff09 =  390  | ie50 = 183  |

//------------------------------------------------------------

//  b = a>>7    |  mz173 = 410  | ff09 =  389  | ie50 = 181  |

//  b = a/128   |  mz173 = 929  | ff09 = 1125  | ie50 = 212  |

//------------------------------------------------------------

First, we see that there's almost no difference between bitshifting and normal operations ( expect for the division in Mozilla ). Then, have a look at the value of loopCount and let's be honest : we never process an operation 262,144 ( that is 512x512 !! ) times in our inner loops in DHTML.

What do we learn from these numbers ?

• Mozilla has a real problem to handle numbers, and is generally 2+ times slower than IE.
• Mozilla has an even bigger problem with divisions.
• nonetheless in most cases, there's no clear performance advatange to use bitshifting over normal division or multiplication.

However, bitwise operations allows far more interresting things than simply an alternative to division and multiplication. They offer the possibility to use fixed point maths and even to combine several variables in a single one. Used that way, the advantages of bitwise operations makes no doubt.

Later, I'll try to see if the orignial resolution of an image have an impact on the perfomance of a script.

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Well, bitshifting in JavaScript is nothing like bitshifting in C/C++. In JavaScript, where numbers are double precision floating point, there are several operations that need to be done that you would not see in a C/C++ context. For example, bitshifting is done by the integer unit of most processors. This means that for bitshifting to work on your JavaScript number, you need to convert both terms of your bitshifting expression to integers - the number you are shifting to a signed integer (32 bit), the number you are shifting by to an unsigned integer (also 32 bit.) Then you zero out all but the five least significant bits of the unsigned integer, after which you perform the bit shifting operation. Following this, you then need to covert the number back to double precision floating point for further usage in JavaScript. Examplifying with the PPC 970 processor, most simple integer actions (such as) bitshifting takes a single cycle while the most efficient floating point operations take seven cycles (indifferent of them being single or double precision). Now, the things is that JavaScript can use the floating point processing unit directly, but needs to do all those other operations for being able to perform bitshifting. Thus, bitshifting is far from as straight forward as it would be in a language which is geared more at performance and less at ease of use, which explains the lack of performance improvement by using bitshifting instead of multiplication and division.

I did some more extensive benchmarking on bitshifting, based on poi's code:

var

    l=262144,

    a=198798,

    i=50,

    d=new Date;

do

    do // Uncomment the one you want to test.

//        b=a<<7;

//        b=a*128;

//        b=a>>7;

//        b=a>>>7;

//        b=a/128;

    while(0<--l)

while(0<--i)

prompt(i=(new Date-d)/50,i);

The results on Windows (an Athlon 1333 MHz) were as expected, but the Mac (G3 900MHz, should be about equal to the Athlon) results were somewhat surprising. It seems like Microsoft has really optimised the number handling in JScript, again confirming that Microsoft has placed more importance at raw number crunching than at object handling.

Well, the results tables:

browsers            a<<7    a*128   a>>7    a>>>8   a/128

  Mac:JScript

    msn2.0.3        7.94    7.9     8.36    8.06    9.48

    iem5.2.3        9.24    9.22    9.46    9.22    11.16

  Mac:linear_b

    op7.6*          22.44   20.34   22.42   22.26   20.54

  Mac:JavaScriptCore<--KJS

    saf1.2.3        23.18   23.08   23.16   23.18   25.48

    shi0.9.2.1      23.12   23.82   23.1    23.82   23.34

  Mac:SpiderMonkey

    cam0.8b         31.5    31.32   32.8    33.46   40.3

    ff0.8           32.54   32      32      32.4    53.08 

    ff0.9.3         32.58   31.92   35.24   35.16   49.72

    ff0.10.1        33.16   34.52   37.08   37.1    58.94

  Win:JScript

    ie6.0sp1w       7.42    7.2     7.02    7.62    8.02

    ie5.5sp2w       6.6     6.8     6.22    6.22    7.42

    ie5.0sp2w       6.6     6.6     6.82    6.82    7.02

  Win:linear_b

    op7.6**         17.22   16.22   16.62   16.62   16.62

    op7.54***       16.42   15.82   18.02   16.62   16.62

    op7.23****      20.84   20.22   22.02   21.82   20.42

    op7.02*****     19.02   19.22   20.82   19.24   20.44

  Win:SpiderMonkey

    ff0.10.1        24.84   24.44   25.44   27.64   45.88

    moz1.8a1        25.64   26.24   27.24   27.24   44.86



* Opera 7.6 build 1872 for Mac OS X.

** Opera 7.6 build 7130 for Windows

*** Opera 7.50 build 3733 for Windows

**** Opera 7.23 build 3227 for Windows

***** Opera 7.02 build 2668 for Windows

It should be noted that the expressions a>>7 and a/128 doesn't give the same results, however. The division does not create an integer number. If you change the value of a to 198784, which makes a>>7 and a/128 give the same result, you get an entirely different result on SpiderMonkey browsers. For exampe, ff0.10.1 on windows then gave the results:

26.22   25.44   26.84   26.24   27.44

--
var Liorean = {
prototype: XHTMLGuru.prototype,
abode: "http://liorean.web-graphics.com/",
profile: "http://codingforums.com/member.php?u=5798"};

(Edited by liorean on 10-12-2004 20:32)

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Not sure if this is helpful or not, but certainly I've found that regardless of speed, when doing dynamic image resizing, it is helpful to have images at various sizes, so during the resizing operations, these images can be swapped in. I'd do this because the image resize code available via the browser will never be as good as resampling the image in Photoshop, etc.

I used this to good effect when doing the cocktail / reciple lounge for the Baileys website - images would appear large at the front, and as they rotated round, the browser would shrink them down. At pre-determined stages, I'd swap in ready-shrunk images and let the browser shrink those until the next pre-determined stage, etc. This avoided a lot of crappy-looking small images.

Dan

BillyRayPreachersSon: What you did is called mip-mapping

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

so is there an actual outcome to my original question !?
mip-mapping is an age old cheat we all used in the old days (although I forgot to use it nowadays!)
Look at the original question - the question was regarding how the renderer dealt with it, not the various browser computation of binary. I'm sure the renderer - sorry if I didn't wade through the personal arguments.. that sort of crap stops me even looking at these boards (hope you've made freinds now, you two).

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

Was going off the point tho, don't you think?