Recent posts

#61

The Workshop / Re: A useful tool: BMP data vi...

Last post by sinsi - November 22, 2024, 05:33:15 PM

What do you mean, "info size = 379,766,016"?

379766016:   00 00 00 00 00 49 49 51 51 51 51 51 51 51 51 51

There was one glaring error in the memory addresses of each line of pixels which I just fixed, but that only affects the number shown before each line. (Take a look at the output, it'll jump out atcha.)

But not atchoo

You might want to sync the thread, if someone loads another bitmap before the thread is finished you might get some interesting things happening...

[I'm not allocating any memory inside that code]

#62

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 05:17:56 PM

What do you mean, "info size = 379,766,016"?

The file you posted is about 9MB, which is about right; typically the text output is ~3X the size of the BMP.

There was one glaring error in the memory addresses of each line of pixels which I just fixed, but that only affects the number shown before each line. (Take a look at the output, it'll jump out atcha.)

Yeah, it's slow.

So about the thread: do I need to mess around with WaitForMultipleObjects() or WaitForSingleObject() or some such to make the program responsive while that thread is executing? I'm definitely not an expert on using threads. (I like to wear natty ones, though.)

Oh,, and another thing: looking at Task Manager while this thing's grinding away, I see memory usage steadily climbing, which I don't understand at all, because I'm not allocating any memory inside that code. So what the hell is going on there? I'm not even calling any Win32 functions there, not doing anything with any controls (like the edit control): I'm just stuffing text into a buffer.

I am using wsprintf(): could that be hogging all that memory?
No, because I'm only using that for 32bpp images.

#63

The Workshop / Re: A useful tool: BMP data vi...

Last post by sinsi - November 22, 2024, 03:15:53 PM

Code Select Expand

BMP width: 2002
BMP height: 1505
no. planes: 1
bits/pixel: 8
bitmap size: 3016020 bytesStill takes ages and the dialog is unresponsive.

Code Select Expand

379766016: 00 00 00 00 00 49 49 51 51 51 51 51 51 51 51 51 BMP size  =   3,016,020
info size = 379,766,016

Hmmm...

#64

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 02:18:00 PM

It does run much faster than the original version.

[CloseHandle]

#65

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 12:31:55 PM

The compute-intensive code now runs in a worker thread, which I would have thought would solve the nonresponsiveness issue, but it hasn't. Still, this version is an improvement. Seems pretty bulletproof.

I took all the code that takes a long time to execute (displaying the palette and especially the bitmap data) and put it in a separate subroutine. I then start it thus:

Code Select Expand

;========================================
; Start worker thread to crunch BMP data:
;========================================
INVOKE CreateThread, OFFSET ThreadSecAttr, 0, OFFSET ProcessBitmapData,
NULL, 0, NULL

The thread routine ends so:

Code Select Expand

; Free buffers:
INVOKE HeapFree, HeapHandle, 0, FileBuffer
INVOKE HeapFree, HeapHandle, 0, TextBuffer

INVOKE ExitThread, 0
RET

So when you run this, you can still move the dialog window around while it's crunching away. However, you shortly get the "busy" cursor and the title says "not responding". I thought that having code execute in a separate thread would fix this; why didn't it? Nothing in the main program is waiting on the threaded subroutine to complete.

Something else I don't understand--the Micro$oft documentation for CreateThread() says

The thread object remains in the system until the thread has terminated and all handles to it have been closed through a call to CloseHandle.

So CreateThread() returns a handle: what am I supposed to do with it? I could close it right after the call to this function, but wouldn't that mess up the thread which is (or may be) still executing? Or should I store the handle and close it later? But when?

I guess I still have a few things to learn about Windows threads.

#66

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 09:54:31 AM

Progress: dynamic memory allocation implemented, like it shoulda been done from the get-go.

But as always, 2 steps forward, 1 step back: now there's a fault on exit, hard to debug since it ends up somewhere in ntdll territory.

Also, the suspended wait is just too long for large BMPs. Seems like the only solution is to put all that computation into a separate thread. Next up.

#67

The Workshop / Re: A useful tool: BMP data vi...

Last post by sinsi - November 22, 2024, 09:25:09 AM

I tend to write this sort of program to work out the structure of things (like here, trying to figure out the bitmap format). Sometimes MSDN can be a bit cryptic to a non-C programmer.

For example, one of the bitmaps I tried with this program had horiz. res and vert. res set to 0, which puzzled me until I looked at the header and saw that it is measuring pixels per metre. No idea why you would want that measurement 

#68

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 08:24:16 AM

If you're going to edit a BMP, then use a graphics editor (like Paint Shop Pro here), not a stupid  hex editor.

Well thats all  I could think of, to see the bitmap data.     Carry on.

#69

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - November 22, 2024, 08:15:37 AM

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

Personally, I would use a hex editor myself. But you never know about anyone else.

Sure, one could use a hex editor. But you'd have to work out where the BMP header ended, where the palette data was, where the bitmap data started, all that. The motivation for this was to display all that data without having to wade through the hex dump.

Maybe this tool could/should use a hex-dump format in displaying the palette and bitmap data? Maybe even allow editing? Ugh; lotsa lotsa work there.

No, I think I'll stick to read-only for this version at least. If you're going to edit a BMP, then use a graphics editor (like Paint Shop Pro here), not a stupid  hex editor.

Anyhow, I'm open to suggestions.

#70

The Workshop / Re: A useful tool: BMP data vi...

Last post by zedd151 - November 22, 2024, 08:10:32 AM

One basic question, though, before I start revamping this code:
Do you think anyone's actually going to use all this bitmap data?
I'd hate to get this working all nice and perfect but to no practical use.

(The displayed text will be larger than the BMP file)

Personally, I would use a hex editor myself. But you never know about anyone else.

Speaking of hex editors, I had played around a bit with trying to write one years ago. The trick to that is to not try to display all the data at one time, but only portions of it from a small buffer... if I can find that half finished code, I might post it some day. Later: I looked for it, but did not find it.