Hi all,
I have a curious question which might sound silly.
How does applns like MS Paint open JPEG files and print them on the screen?
Will the concerned appln apply a decompressing algorithm before opening
them?
Thanks in advance.
Hi all,
I have a curious question which might sound silly.
How does applns like MS Paint open JPEG files and print them on the screen?
Will the concerned appln apply a decompressing algorithm before opening
them?
Thanks in advance.
Not everything that can be counted counts, and not everything that counts can be counted
- Albert Einstein.
No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
- Herbert Mayer
Yes, specifically they'll use the JPEG decompression algorithm on the JPEG files.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Thank u, Salem.
Then I guess the Bitmap files should load faster
than the JPEG files as no such algorithm is necessary
to decompress them.
Is this correct?
Not everything that can be counted counts, and not everything that counts can be counted
- Albert Einstein.
No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
- Herbert Mayer
Thank u, brewbuck.
I have overlooked the h/w side.
Not everything that can be counted counts, and not everything that counts can be counted
- Albert Einstein.
No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
- Herbert Mayer
It doesn't go without saying that this shouldn't discourage you from using uncompressed format in certain contexts. For small files, for instance, there is hardly any loss in speed from the HD loading part of the process. As such, a compressed format will be slower because it will then have to go through the decompression algorithm. Naturally this only becomes an issue when batch processing files.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
The slowest processor on the market today is still faster than the fastest drive. So sorry Mario, btu compressed data will aways load faster unless the file size is trivial (less than the minimum allocation unit) and the decompression is unnecessarily slow. This wont happen in any real world comrpession routine, although you could hack one up to make it appear its possible.
It's irrelevant. Small BMP files will load faster if they are not compressed. No matter what he says.
EDIT: on MS Windows, at least.
Last edited by Mario F.; 04-14-2008 at 03:20 PM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
How many lines of code do you guys think something like MS paint is ?
=========================================
Everytime you segfault, you murder some part of the world
Several thousand, but it's hard to estimate exactly - depends a lot on style, amount of comments, and choice of methods for solving common problems.
There are 36 different menus + 16 tools, and if you simply implement those as simply as possible:
You have 7 lines per functionality: 52 * 7 = 364 lines of code from SIMPLEY managing the menus.Code:switch(menuchoice) { case XXXX: funcXXXX(); break; case YYYY: funcYYYY(); break; ... } void funcXXXX() { return; } void funcYYYY() { return; }
[Yes, we could use a function table and get one line instead of the 3 for the switch, which makes it 52 * 5 lines instead -> 260 lines].
That's the absolute minimum to just do nothing - most of those menu's do SOMETHING.
It's a fair assumption that most menu functions will consist of between 15 and 400 lines of code - say an average of 100 lines -> 52 * 50 => 5200 lines of code.
I suspect it's MORE than that, because paint supports many different pixel formats (colour depths), which makes some functions multiply into one per colour depth. Many things may be common, but others will have to differ because drawing in 16 bpp or 32 bpp require slightly different code. I'd guess this adds another 1000-2000 lines.
There are also 8 file-formats, and whilst most of the time it probably doesn't matter, add another 10-50 lines to save/load/create different types of bitmap files (e.g. jpeg, BMP, TIFF, etc) - most of this is handled by common Windows code, but at the very least you need to tell Windows which variant you want when saving it. Say this adds another 8 * 25 = 400 lines of code.
So as a total, I would guess at least 7000 lines of code. Highly likely it's more like 15000.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
15,000 ?
Urgh, that's too much, will probably take months.
=========================================
Everytime you segfault, you murder some part of the world
Or more... The problem isn't producing 15000 lines, it's making sure they all work and do the right thing at all times. I'd estimate 500-1000 lines of brand new code a week - assuming you know exactly what the code should do - of course, sometimes you can produce a lot more, but other weeks you'll have provided 5 lines of new code at the end of the week, because you spent all the time fixing some complicated problem which didn't provide any more code, just fixing existing lines to work correctly.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.