🚀 go-pugleaf

In article <4cemir$6vb@redstone.interpath.net>,
Jumpstile Turner <fortunat@interpath.com> wrote:
>  Hi all.  Has anyone successfully compiled and linked the IJG JPEG engine 
>with a Win32 compiler?  I can compile it fine and the resulting LIB file works 
>great when linking it into the included test applications; however, if I try 
>to link it with my GUI apps I get some really odd errors.   It links fine but 
>doesn't work! I'm using Borland C++ 4.52 (maybe this is my problem. (-: )    
>Basically stepping through with the debugger there is an assignment statement 
>in one of the modules that just doesn't do anything.  I mean nothing.  If I do 
>the assignment by hand with the debugger it works.  For example, the 
>assignment is as follows:
>
> cinfo->output_width = cinfo->image_width;
>
>cinfo->output_width is 0 and cinfo->image_width is say 289.  After the above 
>assignment nothing changes.   I'm far from a c++ expert and I've never 
>encountered something like this before.  If someone has compiled this lib 
>under Win32 I'd appreciate it if they could mail it my way.  I'd like to see 
>if its my compiler settings or just my ignorance. ;)   The big problem I can't 
>figure is that the compiled lib works fine linked with the test programs.  I 
>tried copying the code from the examples line for line but it just won't work 
>under the GUI.

I also have the libs "working", compiled under VC++ 2.2.  There are some 
weird problems, mainly with the cinfo variables not tracking right.  It is
probably something dumb on my part.  I had a problem with:

if( cinfo.next_scanline < cinfo.image_height) {
   blah blah...;
   jpeg_write_scanlines(blah);
   }

cinfo.next_scanline stays at 0.  I fixed this by adding a tracking
uint variable scanline into the loop and compared it to cinfo.image_height.

scanline = 0;

while( (cinfo.next_scanline < cinfo.image_height) &&
       ((unsigned int) scanline < cinfo.image_height) ) {
   blah blah...;
   jpeg_write_scanlines(blah);
   scanline++;
   }

Although this did not fix the lib, it did get my project going.

It seems that the cinfo variables do not auto-increment at all.

I was going to compile/link project with all the modules directly
instead of using a static lib, that way I could debug it all
easier.  Well, too much code, too little time.  Plus the project
was working so why?  ;)

If you do figure out what it is, I would like to fix my libs too.







	

-- 
Mike - mikemc@macshack.com  -  Home of the JEO-Counter, graphic WWW counter
 /---------------------------------------\   My opinions belong to me, 
| Visit us at http://www.macshack.com     |  myself and I, not my employer,
 \......................................./   the government or my wife...:)

fortunat@interpath.com (Jumpstile Turner) writes:
> Hi all.  Has anyone successfully compiled and linked the IJG JPEG engine
> with a Win32 compiler?  I can compile it fine and the resulting LIB file
> works great when linking it into the included test applications; however, if
> I try to link it with my GUI apps I get some really odd errors.

I can tell you what's probably going on here: structure interpretation
mismatch, ie, the IJG library thinks the offsets of fields inside the
cinfo struct are different from what your surrounding application thinks.

Windoze applications seem to be particularly prone to this kind of
problem.  I can name two possible causes right off the bat:
  * Compiling library and calling app with different structure packing
    rules (#pragma pack or the equivalent compiler switch).
  * Compiling them with different declarations for "boolean".  The IJG
    code by default defines boolean = int, but Windows prefers
    boolean = unsigned char.  Theoretically you should get a compile
    error if both typedefs are visible in one compilation, but maybe
    Borland fails to complain about it.

If neither of those explain your problem, you'll have to do some more
digging, but I'll bet lunch that the problem is of this general ilk.

Your debugger is probably using symbol table entries generated by the
surrounding program, BTW.

This sort of problem has been reported enough times that the next release
of the IJG code will include defenses against it: if the library's idea
of sizeof(cinfo) doesn't match the application's, you'll get an immediate
failure exit with a specific error message.  This will be in v6a which 
I hope to have out in a week or two.

If you find that the problem is *not* a structure mismatch, but has some
other root, I'd appreciate receiving the details at jpeg-info@uunet.uu.net.

			regards, tom lane
			organizer, Independent JPEG Group

fortunat@interpath.com (Jumpstile Turner) wrote:

>  Hi all.  Has anyone successfully compiled and linked the IJG JPEG engine 
>with a Win32 compiler?  I can compile it fine and the resulting LIB file works 
>great when linking it into the included test applications; however, if I try 
>to link it with my GUI apps I get some really odd errors.   It links fine but 
>doesn't work! I'm using Borland C++ 4.52 (maybe this is my problem. (-: )    
>Basically stepping through with the debugger there is an assignment statement 
>in one of the modules that just doesn't do anything.  I mean nothing.  If I do 
>the assignment by hand with the debugger it works.  For example, the 
>assignment is as follows:

> cinfo->output_width = cinfo->image_width;

>cinfo->output_width is 0 and cinfo->image_width is say 289.  After the above 
>assignment nothing changes.   I'm far from a c++ expert and I've never 
>encountered something like this before.  If someone has compiled this lib 
>under Win32 I'd appreciate it if they could mail it my way.  I'd like to see 
>if its my compiler settings or just my ignorance. ;)   The big problem I can't 
>figure is that the compiled lib works fine linked with the test programs.  I 
>tried copying the code from the examples line for line but it just won't work 
>under the GUI.

I had the same problem. It turned out that the data alignment settings
were different for the library and the application, which means that
the application and the library expect the data items in a struct to
be at different adresses. This is why your debugger doesn't see any
change in the variables. You should also take care for redefinitions
of boolean, which is declared to be a (32 bit) int in the jpeg
headers, but to be a (8 bit) character in Microsofts rpc.h.


--
Dr. Johannes Stahl   Abt. Radiodiagnostik
Radiologische Klinik, D66421 Homburg/Saar (GERMANY)
Tel.: +49 6841 164600  Fax: +49 6841 164696
e-mail: rajsta@med-rz.uni-sb.de
http://www.med-rz.uni-sb.de/med_fak/radiodiagnostik/index.html

In article <TGL.96Jan3202549@netcom21.netcom.com>, tgl@netcom.com said:
>  * Compiling them with different declarations for "boolean".  The IJG
>    code by default defines boolean = int, but Windows prefers
>    boolean = unsigned char.  Theoretically you should get a compile
>    error if both typedefs are visible in one compilation, but maybe
>    Borland fails to complain about it.
>
>If neither of those explain your problem, you'll have to do some more
>digging, but I'll bet lunch that the problem is of this general ilk.

  Well I think this is my problem.  I don't know how to go about fixing it 
though.  Being as my application is a GUI application I NEED to include the 
windows.h file, so "BOOLEAN" will be defined as an unsigned char, however 
"boolean" is defined in one of the jpeglib includes as int.  If I went through 
all the source and changed "boolean" to "BOOLEAN" would this screw up jpeglib? 
Being as the source uses 0 for FALSE and 1 for TRUE I don't see why this 
shouldn't work.  I'll have to give it a go.

  Incidently as of right now I converted all the stdlib functions into Windows 
API functions (i.e. CreateFile instead of fopen, ReadFile instead of the 
JFREAD macro, HeapAlloc instead of malloc) and everything appears to work 
until I try to allocate a buffer with the jpeglib's memory allocation 
functions.  Then I get an invalid page fault.  This is with using the decoding 
routine from example.c.  I haven't been able to figure out the cause of this 
one.  It will do this even if I use malloc instead of HeapAlloc.  Time for 
more experimentation.

  Oh yes, and lastly, with the borland BCC32 command line compiler, jdmerge.c 
will not compile.  I get an internal backend C1107 error at line 280.  This 
seems like a bug in the borland compiler. It will compile fine if I use 
BCC32A, the alternate compiler. I have to undefine UPSAMPLE_MERGING_SUPPORTED 
so it will skip the contents of jdmerge.c to get it to compile with the 
standard WIN32 compiler.

                -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

fortunat@interpath.com (Jumpstile Turner) writes:
> tgl@netcom.com said:
>> * Compiling them with different declarations for "boolean".  The IJG
>> code by default defines boolean = int, but Windows prefers
>> boolean = unsigned char.

>   Well I think this is my problem.  I don't know how to go about fixing it 
> though.  Being as my application is a GUI application I NEED to include the 
> windows.h file, so "BOOLEAN" will be defined as an unsigned char, however 
> "boolean" is defined in one of the jpeglib includes as int.

Just change the definition of boolean in jmorecfg.h.  There's specific
advice to do that for Windows apps in install.doc, btw.

> Incidently as of right now I converted all the stdlib functions into Windows 
> API functions (i.e. CreateFile instead of fopen, ReadFile instead of the 
> JFREAD macro, HeapAlloc instead of malloc) and everything appears to work 
> until I try to allocate a buffer with the jpeglib's memory allocation 
> functions.  Then I get an invalid page fault.

Hm.  That one I don't have an answer for offhand.  Which memory manager
back end are you using --- jmemnobs.c, or something more complex?

> Oh yes, and lastly, with the borland BCC32 command line compiler, jdmerge.c 
> will not compile.  I get an internal backend C1107 error at line 280.  This 
> seems like a bug in the borland compiler.

Yes, it is.  Here's the latest dope from the current version of install.doc:


Borland C++ 4.5 fails with an internal compiler error when trying to compile
jdmerge.c in 32-bit mode.  If enough people complain, perhaps Borland will fix
it.  In the meantime, the simplest known workaround is to add a redundant
definition of the variable range_limit in h2v1_merged_upsample(), at the head
of the block that handles odd image width (about line 268 in v6 jdmerge.c):
  /* If image width is odd, do the last output column separately */
  if (cinfo->output_width & 1) {
    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* ADD THIS */
    cb = GETJSAMPLE(*inptr1);
Pretty bizarre, especially since the very similar routine h2v2_merged_upsample
doesn't trigger the bug.


			regards, tom lane
			organizer, Independent JPEG Group

Mike McCammant (mikemc@macshack.com) and Jumpstile Turner
<fortunat@interpath.com> both wrote about problems with the
IJG JPEG Engine under Win32.

Here we have got it working using VC++ 2.2.  We had some
problems at first, similar to the problems that were described.

The source of the problems turned out to be different type
definitions of the "boolean" type.  It was defined to be one
number of bytes in the library compilation and another in our
application code.  As a result all the structures were accessed
differently by the different modules.  Once we identified this
problem it was a minor adjustment to fix it.

Could this be the problem that y'all are having?

-- Russell

In article <TGL.96Jan5065424@netcom21.netcom.com>, tgl@netcom.com 
said:
>Just change the definition of boolean in jmorecfg.h.  There's 
specific
>advice to do that for Windows apps in install.doc, btw.

  This I did and it solved a LOT of problems. :) Thanks.  I didn't 
see the reference in install.doc.

>> API functions (i.e. CreateFile instead of fopen, ReadFile 
instead of the 
>> JFREAD macro, HeapAlloc instead of malloc) and everything 
appears to work
> 
>> until I try to allocate a buffer with the jpeglib's memory 
allocation 
>> functions.  Then I get an invalid page fault.
>
>Hm.  That one I don't have an answer for offhand.  Which memory 
manager
>back end are you using --- jmemnobs.c, or something more complex?
>

  Jmemnobs.c.  After much fudging around with the code I finally 
got it going. I'm not sure exactly what change made the difference. 
 I've had so many problems getting this thing to compile my head is 
spinning.  I think I'm going to go get VC++ 4.0. :)  

  Unfortunately I still can't get the library to work with my 
current application.  I made a short and quick Windows app to test 
how the library functions under the GUI and now I can get it to 
work every time with that, but if I try to integrate it into the my 
major project it chokes like it always did.  I still get the 
strange structure interpretation problems.   I've changed every 
compiler setting I can think of (including making sure the 
alignment options match like someone mentioned) and I've concluded 
that it must be something in one of my includes because no change I 
make seems to fix it.  Checking the cinfo structure after it comes 
back from jpeg_read_header shows that cinfo.image_width and 
cinfo.image_height are correct, however almost every field with  
"output_xxxx" is way off, either 1, 0, or some rediculous number 
like 7988774.  Of course this causes every other call after that to 
choke and I end up with an invalid page fault in Kernel32.dll.  
This library is pretty picky! :)  

>Yes, it is.  Here's the latest dope from the current version of 
install.doc
>:
>Borland C++ 4.5 fails with an internal compiler error when trying 
to compil
>e
>jdmerge.c in 32-bit mode.  If enough people complain, perhaps 
Borland will 
>fix
>it.  In the meantime, the simplest known workaround is to add a 
redundant
>definition of the variable range_limit in h2v1_merged_upsample(), 
at the he
>ad
>of the block that handles odd image width (about line 268 in v6 
jdmerge.c):
>  /* If image width is odd, do the last output column separately 
*/
>  if (cinfo->output_width & 1) {
>    register JSAMPLE * range_limit = cinfo->sample_range_limit; /* 
ADD THIS
> */
>    cb = GETJSAMPLE(*inptr1);
>Pretty bizarre, especially since the very similar routine 
h2v2_merged_upsam
>ple
>doesn't trigger the bug.

  Thanks for the tip!  I'll make the changes.  I don't know if you 
are aware of this,  but if you use the BCC32a instead of plain 
BCC32 it will compile without a hitch.  The BCC32a is for Pentium 
scheduler support and of course has a different back-end than 
BCC32.


  I haven't gone through all the code yet, but all I really need to 
do is decode a JPEG file to its normal dimensions (no scaling) at 
24 bits per pixel.  How difficult would it be to strip out 
everything except support for that.  At a quick glance it seems 
everything is tightly integrated.  I also don't need any of the 
virtual array functions since I've got over a 2 gig virtual address 
space.

           -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

fortunat@interpath.com (Jumpstile Turner) wrote:

>In article <TGL.96Jan3202549@netcom21.netcom.com>, tgl@netcom.com said:
>>  * Compiling them with different declarations for "boolean".  The IJG
>>    code by default defines boolean = int, but Windows prefers
>>    boolean = unsigned char.  Theoretically you should get a compile
>>    error if both typedefs are visible in one compilation, but maybe
>>    Borland fails to complain about it.
>>
>>If neither of those explain your problem, you'll have to do some more
>>digging, but I'll bet lunch that the problem is of this general ilk.

>  Well I think this is my problem.  I don't know how to go about fixing it 
>though.  Being as my application is a GUI application I NEED to include the 
>windows.h file, so "BOOLEAN" will be defined as an unsigned char, however 
>"boolean" is defined in one of the jpeglib includes as int.  If I went through 
>all the source and changed "boolean" to "BOOLEAN" would this screw up jpeglib? 
>Being as the source uses 0 for FALSE and 1 for TRUE I don't see why this 
>shouldn't work.  I'll have to give it a go.

look at the first lines of my jconfig.h:

#define HAVE_BOOLEAN     // this will avoid redefinition of boolean
// the following line is probably or definitely a hack
// since it implicitly duplifies the definiction from rpcnrd.h
typedef unsigned char boolean;  //conflict with RPCNRD.H  ---
 	 		            //  AAAAArrrrrrggghh!  JST

>  Oh yes, and lastly, with the borland BCC32 command line compiler, jdmerge.c 
>will not compile.  I get an internal backend C1107 error at line 280.  This 
>seems like a bug in the borland compiler. It will compile fine if I use 
>BCC32A, the alternate compiler. I have to undefine UPSAMPLE_MERGING_SUPPORTED 
>so it will skip the contents of jdmerge.c to get it to compile with the 
>standard WIN32 compiler.
You are right, this is a known bug. Most of the IJG library features
work well without UPSAMPLE_MERGING_SUPPORTED.





--
Dr. Johannes Stahl   Abt. Radiodiagnostik
Radiologische Klinik, D66421 Homburg/Saar (GERMANY)
Tel.: +49 6841 164600  Fax: +49 6841 164696
e-mail: rajsta@med-rz.uni-sb.de
http://www.med-rz.uni-sb.de/med_fak/radiodiagnostik/index.html

fortunat@interpath.com (Jumpstile Turner) wrote:

>  Jmemnobs.c.  After much fudging around with the code I finally 
>got it going. I'm not sure exactly what change made the difference. 
> I've had so many problems getting this thing to compile my head is 
>spinning.  I think I'm going to go get VC++ 4.0. :)  

I do not know if this will help you with the api stuff. why don't you
stay with the standard library routines for malloc() read() etc. ?
they work fine. I found that getting the IJG library running with BC
4.x was simple enough. If you want to save the work, i can send you my
port with .IDE file, based on IJG v.5


--
Dr. Johannes Stahl   Abt. Radiodiagnostik
Radiologische Klinik, D66421 Homburg/Saar (GERMANY)
Tel.: +49 6841 164600  Fax: +49 6841 164696
e-mail: rajsta@med-rz.uni-sb.de
http://www.med-rz.uni-sb.de/med_fak/radiodiagnostik/index.html

fortunat@interpath.com (Jumpstile Turner) writes:
> Checking the cinfo structure after it comes 
> back from jpeg_read_header shows that cinfo.image_width and 
> cinfo.image_height are correct, however almost every field with  
> "output_xxxx" is way off, either 1, 0, or some rediculous number 
> like 7988774.

Then you've still got a problem with sizeof(boolean), I'd bet,
or else a structure packing rule (#pragma pack).  Are you sure
you recompiled everything affected by the header files you changed?

It might help to #include jpeglib.h *before* including any Windows-
specific headers... if one of their headers is leaving #pragma pack
in a nondefault state, that could cause this problem.

			regards, tom lane
			organizer, Independent JPEG Group

In article <TGL.96Jan8083559@netcom23.netcom.com>, tgl@netcom.com said:
>
>fortunat@interpath.com (Jumpstile Turner) writes:
>> Checking the cinfo structure after it comes 
>> back from jpeg_read_header shows that cinfo.image_width and 
>> cinfo.image_height are correct, however almost every field with  
>> "output_xxxx" is way off, either 1, 0, or some rediculous number 
>> like 7988774.
>
>Then you've still got a problem with sizeof(boolean), I'd bet,
>or else a structure packing rule (#pragma pack).  Are you sure
>you recompiled everything affected by the header files you changed?
>
>It might help to #include jpeglib.h *before* including any Windows-
>specific headers... if one of their headers is leaving #pragma pack
>in a nondefault state, that could cause this problem.
>
>                        regards, tom lane
>                        organizer, Independent JPEG Group


   Well, I've got it working flawlessly now. :) In fact the problem was 
entirely related to one specific Borland compiler setting.  Allocate 
enums as int.  This was causing all sorts of problems.  I had to have 
this set or borland packs enums.  I was looking for the word 
"structure"and I didn't pay much attention to this setting.  Like I 
figured, it was something stupid on my end.
   Incidently, I changed (and have been changing) a lot of stuff over 
to Win32 API calls, memory and file handling.  It sure seems a lot 
faster now as opposed to using the standard C stuff, but this might be 
my imagination.  Maybe I'll add multi-threading now that I have a 
handle on this thing. :)


   Thanks for all the help.  You really cleared up a lot of things for 
me and I learned a LOT (About the JPEG code too. :) )

             -Scott  


P.S.   If anyone reading this thread is interested in my hacked up 
version of the .LIB let me know.  I've been using it on hundreds of 
images now to make sure there are no strange memory leaks and it hasn't 
burped even once.



------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

fortunat@interpath.com (Jumpstile Turner) writes:
>> Checking the cinfo structure after it comes 
>> back from jpeg_read_header shows that cinfo.image_width and 
>> cinfo.image_height are correct, however almost every field with  
>> "output_xxxx" is way off, either 1, 0, or some rediculous number 
>> like 7988774.
> 
>Then you've still got a problem with sizeof(boolean), I'd bet,
>or else a structure packing rule (#pragma pack).  Are you sure
>you recompiled everything affected by the header files you changed?
> 
>It might help to #include jpeglib.h *before* including any Windows-
>specific headers... if one of their headers is leaving #pragma pack
>in a nondefault state, that could cause this problem.

Just as an affirmation, we use the IJG version 5a with no problems
under Windows NT and Windows 95.

It would be nice if it supported Monochrome and 16 color BMP's, but
other than that its totally bulletproof!

rjf

P.S. Thanks Tom!
-- 
~/.signature

fortunat@interpath.com (Jumpstile Turner) wrote:

>   Incidently, I changed (and have been changing) a lot of stuff over 
>to Win32 API calls, memory and file handling.  It sure seems a lot 
>faster now as opposed to using the standard C stuff, but this might be 
>my imagination.  

The right way to do this is to write your own source and destination
drivers. I wrote a pair to read and write from/to MFC CArchives, and
used this to integrate it into a JPEGImage class that I plugged into
the Image clases from Barkakati's _Visual C++ Developer's Guide_.

This is a pretty slick way to go - I can just JPEGimage->serialize()
onto a TCP connection! Using the MFC 4.0 CSocket class, it only takes
a couple of lines of code to open a CSocket, open a CArchive onto the
CSocket, and then serialize the image. Poof! It shows up on my little
Perl server at the other end. (And will start showing up on my web
site, once I write the buffering code into the Perl program and the
NSAPI function to read it from the memory buffers...) 
________________________________________________________________________
jtara@live.net  A new video clip (Netscape 1.1+) of San Diego Bay every half hour:
 <URL:http://live.net/sandiego/> Rated top 5% & "best 1000" by Point Communications
jtara@mediashare.com Tools and services for CD-ROM and online catalogs:
 <URL:http://www.mediashare.com/> Also rated top 5% by Point Communications

 

In article <4crai5$ear@hades.rz.uni-sb.de>, rajsta@med-rz.uni-sb.de 
said:
>
>fortunat@interpath.com (Jumpstile Turner) wrote:
>
>>  Jmemnobs.c.  After much fudging around with the code I finally 
>>got it going. I'm not sure exactly what change made the difference. 
>> I've had so many problems getting this thing to compile my head is 
>>spinning.  I think I'm going to go get VC++ 4.0. :)  
>
>I do not know if this will help you with the api stuff. why don't you
>stay with the standard library routines for malloc() read() etc. ?
>they work fine. I found that getting the IJG library running with BC
>4.x was simple enough. If you want to save the work, i can send you my
>port with .IDE file, based on IJG v.5
>

   Well, I've got it running like a champ now. Thanks for the offer 
though.  Incidently, malloc() and free() are measureably slower under 
Windows 95.  These generate calls to GlobalAlloc which are still in the 
Win32 API just for compatability. Under Win32 you want to use HeapAlloc 
or VirtualAlloc if you can.  I've also been looking at sucking the JPG 
files into RAM and decoding them from ram because JPG's tend to be 
rather small while they're compressed. I'm not sure if I'll gain any 
speed benefit from doing so yet.  

    -Scott


------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

In article <4cr8tp$dp7@hades.rz.uni-sb.de>, rajsta@med-rz.uni-sb.de 
said:
>look at the first lines of my jconfig.h:
>
>#define HAVE_BOOLEAN     // this will avoid redefinition of boolean
>// the following line is probably or definitely a hack
>// since it implicitly duplifies the definiction from rpcnrd.h
>typedef unsigned char boolean;  //conflict with RPCNRD.H  ---
>                                    //  AAAAArrrrrrggghh!  JST

  Well, this didn't work for me.  Even if I defined this in some of the 
modules it still choked with the duplicate boolean definition error.  I 
changed all the "boolean" statements to "BOOLEAN" and it works fine 
now.


>You are right, this is a known bug. Most of the IJG library features
>work well without UPSAMPLE_MERGING_SUPPORTED.

  Tom Lane posted a fix for this a few messages back.  I believe he 
said this is addressed in the new version of the IJG engine soon to be 
released in the INSTALL.DOC.


     -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

fortunat@interpath.com (Jumpstile Turner) wrote:

> Incidently, malloc() and free() are measureably slower under 
>Windows 95.  These generate calls to GlobalAlloc which are still in the 
>Win32 API just for compatability. Under Win32 you want to use HeapAlloc 
>or VirtualAlloc if you can.  

I'm not sure that using VirtualAlloc() would be such a good idea,
except for large blocks. malloc() and free() grab large blocks and
then divvy them up, so most of the time when you call malloc() it
doesn't actually go out to the operating system and allocate anything.

Are you sure that GlobalAlloc doesn't wind up calling

>I've also been looking at sucking the JPG 
>files into RAM and decoding them from ram because JPG's tend to be 
>rather small while they're compressed. I'm not sure if I'll gain any 
>speed benefit from doing so yet. 

The IJG library can make use of the ability to "back up" in the file -
that way, it can avoid allocating some buffers in some cases. Not sure
if this really gains you much.

Rather than sucking the files into RAM, though, why not just
memory-map the file?

In my app, I bring the JPG in and out through a CArchive, which
precludes direct access to the file (I could be serializing from/to a
CSocket, for example) and backing up. This would be a case for sucking
it into memory first, IF there is a significant advantage to being
able to back up.

Right now, though, I'm perfectly happy with malloc() for allocation
and letting the default MFC code (in CDocument) read the file for me.
It seems significantly faster than Lview Pro (not sure why - I have
the 32 bit version - is it not using the IJG code?) so I'm happy.
 

________________________________________________________________________
jtara@live.net  A new video clip (Netscape 1.1+) of San Diego Bay every half hour:
 <URL:http://live.net/sandiego/> Rated top 5% & "best 1000" by Point Communications

 

In article <310110c0.44581633@news.connectnet.com>, 
jtara@connectnet.com said:
>I'm not sure that using VirtualAlloc() would be such a good idea,
>except for large blocks. malloc() and free() grab large blocks and
>then divvy them up, so most of the time when you call malloc() it
>doesn't actually go out to the operating system and allocate anything.


  Well, I myself use HeapAlloc for the mempry calls.  HeapAlloc is 
smart in that it will use VirtualAlloc if necessary completely 
transparently.

>Are you sure that GlobalAlloc doesn't wind up calling
>

  You didnt finish this line.  I assume you mean GlobalAlloc doesn't 
wind up calling HeapAlloc?  As far as I understand GlobalAlloc still 
calls 16-bit memory rather than 32-bit memory.  I could be wrong, but 
in one of my Win32 books floating around here it states that Win95 
Explorer still uses GlobalAlloc to allocate memory for "Drag and Drop" 
data structures and that this is 16-bit RAM it is allocating.  It also 
states that GlobalAlloc is much slower than using HeapAlloc or 
VirtualAlloc.  I haven't tested this much, but it sure SEEMS slower 
when I switch HeapAlloc calls to GlobalAlloc.  Although this might be 
the power of suggestion. :)  However I've read this in more than one 
place so I'd just assume it was correct.

>The IJG library can make use of the ability to "back up" in the file -
>that way, it can avoid allocating some buffers in some cases. Not sure
>if this really gains you much.
>
>Rather than sucking the files into RAM, though, why not just
>memory-map the file?

   Well, if reading it into RAM from the start isn't any faster than I 
don't think I'll get any speed benefit by converting it to a memory 
mapped file.  After all, its basically just converting file accesses to 
memory accesses.  I would think I'd end up with a little more overhead 
this way, although memory mapped files are certainly usesful.

>In my app, I bring the JPG in and out through a CArchive, which
>precludes direct access to the file (I could be serializing from/to a
>CSocket, for example) and backing up. This would be a case for sucking
>it into memory first, IF there is a significant advantage to being
>able to back up.
>
>Right now, though, I'm perfectly happy with malloc() for allocation
>and letting the default MFC code (in CDocument) read the file for me.
>It seems significantly faster than Lview Pro (not sure why - I have
>the 32 bit version - is it not using the IJG code?) so I'm happy.


  Whatever works is good enough I guess. :)  I find that my compilation 
is at least as fast as LView and noticeably faster for larger JPEG 
images.  Of course changing the DCT options makes a large difference.  
Incidently I don't notice any difference in image quality if I use 
floating point or slow integer DCT as opposed to fast integer.  Other 
than the significantly longer decompression times, there is barely any 
difference at all (that I can see) if there is one.  Is it the same on 
your end?  Perhaps my eyes are failing me. :)


           -Scott

------------------------------------------------
Jumpstile Turner
fortunat@interpath.com
"Sing the Hare Hare, Dance the Hoochie Koo..."
------------------------------------------------

jtara@connectnet.com (Jon Tara) wrote:

>> > Incidently, malloc() and free() are measureably slower under 
>> >Windows 95.  These generate calls to GlobalAlloc which are still in the 
>> >Win32 API just for compatability. Under Win32 you want to use HeapAlloc 
>> >or VirtualAlloc if you can.  

>> I'm not sure that using VirtualAlloc() would be such a good idea,
>> except for large blocks. malloc() and free() grab large blocks and
>> then divvy them up, so most of the time when you call malloc() it
>> doesn't actually go out to the operating system and allocate anything.

This was true in Visual C++ until 4.0.  Now _all_ memory allocation
calls are turned into native calls to the operating system.

Brad

fortunat@interpath.com (Jumpstile Turner) wrote:


>>Are you sure that GlobalAlloc doesn't wind up calling
>>
>
>  You didnt finish this line.  I assume you mean GlobalAlloc doesn't 
>wind up calling HeapAlloc?  As far as I understand GlobalAlloc still 
>calls 16-bit memory rather than 32-bit memory.  I could be wrong, but 
>in one of my Win32 books floating around here it states that Win95 
>Explorer still uses GlobalAlloc to allocate memory for "Drag and Drop" 
>data structures and that this is 16-bit RAM it is allocating.  It also 
>states that GlobalAlloc is much slower than using HeapAlloc or 
>VirtualAlloc.  I haven't tested this much, but it sure SEEMS slower 
>when I switch HeapAlloc calls to GlobalAlloc.  Although this might be 
>the power of suggestion. :)  However I've read this in more than one 
>place so I'd just assume it was correct.

In Win32, GlobalAlloc and LocalAlloc are the same function.  They
allocate memory from the process' 32-bit heap.  There is a difference
between HeapAlloc for backard compatibility in that LMEM_MOVEABLE
allocated handles are doubly indirect pointers (void **) to the
memory.

See Peitrek's "Windows 95 Programming Secrets" for more info.

rm





---
Robert Mashlan | R2M Software
rmashlan@r2m.com http://www.transport.com/~rmashlan
Internet Resources for Windows Developers
http://www.r2m.com/windev/