Re: Firefox and Sound
- From: "Rich Walsh" <spamyourself@xxxxxxxxx>
- Date: 09 Sep 2009 04:19:16 GMT
On Wed, 9 Sep 2009 00:38:29 UTC, tholen@xxxxxxxxxxxx wrote:
Rich Walsh writes:
Well, if an app loads a dll a gazillion times & fails to notice
that its attempts to unload it have failed (which is what I'd see
in debug builds), then it's possible that either the kernel's
in-use counter or some counter in the dll itself might overflow,
causing who-knows-what kind of errors.
Assuming one visits a web page that triggers the use of audio,
It wasn't visiting a web page that triggered the the dlls to be
loaded & unloaded. It was displaying a menu, clicking on an item
in that menu, etc, that caused the load/unload. IOW, any of the
7 events listed in MozSounds.cmd.
would launching and closing Firefox a gazillion times have the
same effect on the system that the current version has?
By "current", I assume you mean 3.5.2 and before. When an app
closes, the the kernel should decrement a dll's use count by the
number of loads that app performed. Whether it actually does is
another matter.
The difference is in scope, not kind. Like I said, both dlls
(mdm & mmio) are loaded just once - only when actually needed,
not when they _might_ be needed - and they're never unloaded.
Until the application closes, when the system does it, right?
Correct.
Note that they're dynamically loaded and not statically linked
solely to enable some hypothetical user who has removed MMOS2
to retain use of the mozilla apps.
I'm confused again. When I build a number-crunching program for
use by somebody else, I always link statically so that all the
necessary library code is included, just in case the somebody
else doesn't have the necessary libraries. What you said sounds
like just the opposite.
You're not familiar with how dlls work? The actual code is never
linked into the app, only references to entry points in the dll.
By "statically linked", I meant that these references are exposed
in the Imports list and are resolved at load-time - if the dll or
specified entry points in it can't be found, the app fails to load.
By "dynamically linked", I meant that the dll is loaded and its
entry points are resolved programmatically. If there are errors,
the app can deal with it and still run successfully - albeit without
whatever features the dll provides.
v3.5.4 is largely a known entity, while v3.7a1pre contains some
significant architectural changes. In addition to my relatively
minor changes to sound, it would be helpful to hear about its
overall performance - in particular, are the windows belonging
to plugins displayed properly?
The first thing I noticed is that the double bolding associated
with -- what's it called, Workplace Sans font -- isn't occurring
anymore. Nice.
Peter did some work on synthetic emboldening about a month ago.
The next thing I tested is whether Firefox could download a large
file. With Firefox 2, I tried to download a file listed as being
4.03 GB in size, but the download manager said it was only 78.8 MB.
After inquiring with the owner of the file, I was informed that
the file size is 78.8 MB in excess of 4 GB, so apparently we're
running into a file size issue with Firefox 2. I told him that
I'd give it a try on Firefox 3.7, which I did. Same problem.
We'll have to look into whether the OS/2 code provides large file
support. BTW... this is an excellent example of where you'd
resolve entry points dynamically rather than at load time. Only
the Warp 4.5 kernel provides this support. If you let the loader
think you need these entry points, then none of the mozapps would
run under the 4.0 kernel.
But 3.7 has an additional problem: right-clicking on the link to
the file produces the expected pop-up menu. I selected the
"Save Link As..." option, which opens the filename dialog, chose
my desired destination directory and clicked on OK. But nothing
happened. No download occurred. So I left-clicked on the link,
clicked on Stop (to avoid having Firefox try to download and
display 4 GB of data), and then used Ctrl+S to save the page,
which is when the Download Manager appeared and said that the
file is only 78.8 MB in size. So the right-click method is
currently broken in addition to the file size issue.
I tried this with several small files and had no problems at all.
Did you also try this with smaller files? It should come as no
particular surprise that if one aspect of large file support is
broken, the other parts may be as well.
So far, no problems with my audio.
You won't really know until you've associated some sound with
menu popups and menu execute, then endured the noise as long
as you can. Like I said, this is a stress test :-)
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
.
- Follow-Ups:
- Re: Firefox and Sound
- From: tholen
- Re: Firefox and Sound
- From: Dave Yeo
- Re: Firefox and Sound
- References:
- Firefox and Sound
- From: Rich Walsh
- Re: Firefox and Sound
- From: tholen
- Re: Firefox and Sound
- From: Rich Walsh
- Re: Firefox and Sound
- From: tholen
- Firefox and Sound
- Prev by Date: Re: Firefox and Sound
- Next by Date: Re: Firefox and Sound
- Previous by thread: Re: Firefox and Sound
- Next by thread: Re: Firefox and Sound
- Index(es):
Relevant Pages
|
Loading
