_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Blitz -> Loading JPG's faster |
|
| Sat, 03 Jan 2009, 23:08 | |
JL235
|
jpegs use quite heavy amounts of compression, so that might be a part of it. You could try timing how fast it is to load with other image libraries using C++. If it's faster then make a dll that loads it and returns an array containing the data. Then you can create a new image in Blitz and copy the pixels across. |
| Sun, 04 Jan 2009, 01:19 | |
steve_ancell
|
I wouldn't bother trying. I would just load the JPEG into Paint.NET, and save it back out as a format that is Blitz friendly.
|
| Sun, 04 Jan 2009, 01:20 | |
Afr0
|
 Then you can create a new image in Blitz and copy the pixels across. No. Don't do that. AFAIK, the pixel-drawing routines in Blitz (DrawPixelFast() and DrawPixel()) are really, really slow. Isn't Blitz3D open-sourced by now? I'm pretty sure I heard Noel talking about it. If that's the case, you could just make a faster routine for loading the images that way. -=-=- Afr0 Games Project Dollhouse on Github - Please fork! 
|
| Sun, 04 Jan 2009, 02:08 | |
|
JL235
|
Afro Slow for use at runtime in a game, but I'd still imagine it's faster then the decompression if it's so noticable. Even if it turns out to be slower, it's an alternative he can investigate.No. Don't do that. AFAIK, the pixel-drawing routines in Blitz (DrawPixelFast() and DrawPixel()) are really, really slow.Isn't Blitz3D open-sourced by now? I'm pretty sure I heard Noel talking about it. If that's the case, you could just make a faster routine for loading the images that way. Steve_Ancell I agree, but I think this is for his image viewing program so he needs to support jpegs.
I wouldn't bother trying. I would just load the JPEG into Paint.NET, and save it back out as a format that is Blitz friendly. |
| Sun, 04 Jan 2009, 02:50 | |
Jayenkai
|
Cheat.. Make thumbnails, and use those instead.. Whenever the proggy encounters a new photo, let it load it in (one new image per frame, don't be going crazy!) On the next frame, scale it down to a resonable size, then save that in a special area somewhere,(I would suggest "Your proggies directory" so that we don't end up with another 60,000 thumbnails around the harddrive) with a unique identifier, so you can get it back afterwards. Now, Blitz will only save as .bmp, so you can either save that way, or perhaps create your own image format that at least compresses a teensy tiny bit. But then you have to deal with loading them all back in again.. (bah!) The biggest issue you'll have with Blitz is that when you hit about 1500 images, it slows RIGHT down, as it tries to clamber for a little bit more space.. Or at least, it does on my Celeron, with 128x115, anyway 
-=-=- ''Load, Next List!''
|
| Sun, 04 Jan 2009, 03:15 | |
|
JL235
|
If you had threads you could pre-load the other images (i.e. the next image) in the background in a new thread. i.e. Whilst I'm looking at img1, img2 and then img3 are being loaded. There are ways you can simulate this in Blitz, but I doubt it won't be as good. For example you could manually read as much of the image as you can over a set period of time. Essentially building your own scheduling system to allow pre-loading the other images. Is this for the image viewing app? Are you making it in BB? I don't think it would be a good choice for an application because it won't be structured very well. For example, are you using a main loop and redrawing everything on each frame? That's not how applications draw themselves. Instead they draw on demand because it's far more efficient. |
| Sun, 04 Jan 2009, 03:42 | |
|
Afr0
|
Hm. I agree with JL235 here. Perhaps even more important than fast pixel drawing in Blitz3D is the addition of threads. If you added that Tiki, you'd be well on your way to a nice program that would perform well, and you'd help other people as well! Here are some command-suggestions: StartThread(MyThreadFunction, String MyThreadID) StopThread(String ThreadID) All the threads could be kept in an internal ThreadPool that wouldn't be accesible from Blitz. Edit: Yes! The Blitz3D SDK forum is here: https://www.blitzbasic.co.nz/Community/topics.php?forum=120 -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sun, 04 Jan 2009, 04:13 | |
|
Jayenkai
|
Even a decent sized jpg image will load in the space of a couple of frame. Keep track of your mills between starting a load and finishing a load, and you can limit how much loads in a frame.. If you thumbnail the catalogue "Building catalogue - Progress bar - People will wait - They're not impatient" then it makes it so much quicker to load them in as you go. You'd still, probably, want to speed up the loading of each image, though. Blitz is slow at loading really big jpgs (2048x2048 taking about 5 secs on my Celeron) In those cases, you might want to maybe read the jpg yourself, although that'll be a bit of a tricky thing to do!! It might help to point out, though, that it actually about 1/2 the time to Createimage(2048x2048) and then WritePixelFast random pixels for the whole image, than it does to actually LoadImage("2048x2048.jpg") (2252 millisecs average for create+write, vs 5148 average loading) The problem is, then, that you're loading so many of them. That's your bottleneck. You just need to do some background loading, and watch when things get too slow. Perhaps if you held a maximum of 100 images in memory at once.. (What's the chances of needing more?!) Then, as the user scrolls through, free out the old, load in the new.. "Stream" the next bunch of images as if you would if the user were speeding through a GTA level. .. As a last point, it might be worth noting that it takes IrfanView about 2 seconds to open the 2048x2048 jpg image.. So, no matter what language you use, you're probably going to hit that same issue.. And, yes, 2048x2048 is a pretty reasonable assumption, considering most of my photos are from ONLY a 3megapixel camera. -=-=- ''Load, Next List!''
|
| Sun, 04 Jan 2009, 05:41 | |
|
JL235
|
2 seconds is more then double the speed of 5. I disagree that people are willing to wait. When switching to the next image in the order it should (and can be) instant. I think pre-loading future images in the background is a must for this kind of application.
|
| Sun, 04 Jan 2009, 06:24 | |
|
Jayenkai
|
The initial loader bar thing would be it generating the thumbnails, when it's initially routing your hard drive. I doubt there's not a photo browser that doesn't do that!! .. Well, except for the Wii's photo channel.. God only knows how that works so damn fast.. -=-=- ''Load, Next List!''
|
| Sun, 04 Jan 2009, 06:27 | |
|
JL235
|
For the photo manager bit of it, yes use thumbnails. But when viewing images you should fully pre-load the next image in line.
|
| Sun, 04 Jan 2009, 06:37 | |
|
Jayenkai
|
Oh, yeah, but then you're into basic Screensaver/slideshow territory.. The hardest part is the manager, where you really need to show hundreds of photos, right there and then. And if it's taking you 5 seconds to load a 2048x2048 jpeg, then 100 photos is a heck of a wait!! -=-=- ''Load, Next List!''
|
| Sun, 04 Jan 2009, 07:16 | |
Stealth
|
I would generate the thumbnails when the images are first imported. -=-=- Quit posting and try Google.
|
| Sun, 04 Jan 2009, 07:38 | |
|
JL235
|
But it doesn't matter if it takes 4-5 seconds in the background if it's done whilst I'm looking at other images!
|
| Sun, 04 Jan 2009, 08:09 | |
|
Jayenkai
|
If you could do that, then it'd be great.. You could have it sit in the background and load up a bit of the image each frame.. But you'd have to code your own jpg loader, 'cos the Blitz one just sits there.. (argh!) This is why Diablo initially suggested the threading. But, no.. On the whole, you probably wouldn't need it once you're in Viewer mode. Because you can load one image, pop it on the screen, and then in the background load up next image, and maybe about 5 either side, (5 ahead, 5 previous) so that if the user starts tapping back, you've got them already too.. If you only load the next image, then when they go to the next one, start again.. If, however, they've sat staring at the image for a while, you'll have a nice buffer ready and waiting.. .. I'd use keyhits instead of keydowns, so you can grab any/all button pushes inbetween each load. -=-=- ''Load, Next List!''
|
| Sun, 04 Jan 2009, 08:39 | |
|
Afr0
|
I still think you should make your own Threadpool in the Blitz3D SDK.
-=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Sun, 04 Jan 2009, 10:40 | |
|
Paul |
With LoadAnimImage() it's possible to load part of an image, maybe that is something to try? Or does it load the whole image and then discard parts of it? worth a try anyway. If it works you could load a few parts of the image every frame thus not making the program fell slow. |
| Sun, 04 Jan 2009, 17:27 | |
|
JL235
|
Jayenkai But, no.. On the whole, you probably wouldn't need it once you're in Viewer mode. Because you can load one image, pop it on the screen, and then in the background load up next image, and maybe about 5 either side, (5 ahead, 5 previous) so that if the user starts tapping back, you've got them already too..I don't see how you could do that easily without threads. When your viewing img1 and it's loading img2, 3 and 4 as an application it'll just freeze for a few seconds on img1 if the event handling and the image loading are performed in the same thread. |
| Sun, 04 Jan 2009, 22:25 | |
|
Stealth
|
The Windows "Image Preview" app loads the next picture while you're looking at one Honestly, there is no way in getting around this. You're stuck loading photos in the background and tricky stuff. It seems like all the popular photo viewing apps take a bit of time and I'm sure those programmers already tried everything to speed up load time. I'm going to just say this is the best for now. -=-=- Quit posting and try Google.
|
| Tue, 20 Jan 2009, 07:30 | |
|
Teasy |
Another work-around is something that Snarty (from way back) used to do which is basically making your own LoadImage. 1) Either load the JPG in manually or use a DLL or someone else's JPG loader (I bet there's one already somewhere). 2) Copy the entire pixeldata using Blitz+'s banks method (LockedPixels) or via Win32 API userlib declarations (MemCopy) and perhaps even more ways  I remember Snarty saying that doing it manually (properly) was many times faster than LoadImage.
|
| Tue, 20 Jan 2009, 07:57 | |
|
JL235
|
But no matter how fast it is, without threads you will always get a freeze when the user tries to view a big image.
|
|
|
| |||
|
| ||||