Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[jegunn]

I may have missed messages on this issue on the mailing list, and if so
apologies. I have used dosemu 1.0.2.1 for a couple of years under RH7.3 on
a dual 1.6GHz Athlon machine, running Generic CADD 6.0 under xdosemu with
wonderful results. I recently upgraded to FC2, (2.6.8) and discovered that
1.0.2.1 would no longer run, so I upgraded dosemu to 1.2.2.0.  This works
fine, but the cadd program now generates its screen a full factor of 50
more slowly than it did before. All of the X and memory settings are
unchanged as far as I can see. The speed change is reminiscent of 
the difference between BIOS graphics and writing directly to screen memory
in the bad old days. Am I likely missing something, or has something 
really changed in the code? The performance is, as I vaguely remember,
more-or-less like it was on an 8 MHz 80286.

Another smaller problem is that setting special VESA modes under X
no longer seems to work--I have used a 1024x740 mode to allow both the 
CADD menubar at the bottom and the window titlebar to exist on a 1024x768
screen, and would like very much now to use a 1280x1024 window on a new
larger display. Neither seems to be recognized by the same vesa listing
code which worked before, at least with the 1024x740 setting. I
upped the vga memory to 2048kB to accomodate the larger setting, but
still with no results.

Thanks in advance for any advice; I would be happy to attach all of
or clippings from my .dosemurc if that would help.

--jim gunn

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[Stas Sergeev]

Hello.

jegunn wrote:
> fine, but the cadd program now generates its screen a full factor of 50
> more slowly than it did before.
Set $_hogthreshold=(0) in your dosemu.conf.

> Another smaller problem is that setting special VESA modes under X
> no longer seems to work
I suggest you to open the bugreport for
that problem and attach the -D9+v log to
it.

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[jegunn]

On Tue, 16 Nov 2004, Stas Sergeev wrote:

> Hello.
> 
> jegunn wrote:
> > fine, but the cadd program now generates its screen a full factor of 50
> > more slowly than it did before.
> Set $_hogthreshold=(0) in your dosemu.conf.

Thanks. I tried this a little while before I got your reply; the 
performance is *very* sensitive to the setting; 3 is more-or-less
OK, but better with zero. I was using 1 before with 1.0.2.1. Did
the priority code change between these versions?
 
> > Another smaller problem is that setting special VESA modes under X
> > no longer seems to work
> I suggest you to open the bugreport for
> that problem and attach the -D9+v log to
> it.

I will do that.

> To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[Bart Oldeman]

On Tue, 16 Nov 2004, jegunn wrote:

> Thanks. I tried this a little while before I got your reply; the
> performance is *very* sensitive to the setting; 3 is more-or-less
> OK, but better with zero. I was using 1 before with 1.0.2.1. Did
> the priority code change between these versions?

yes, certainly. You may even want to try 1.2.1 and see how that behaves,
since there were a few changes between 1.2.1 and 1.2.2 that can be
regressions in certain cases (we'll have to look at this more closely).

There's a big difference between hogthreshold 1 and 2, then to 3 4 5 etc
it goes more gradually.

With "0" you pretty much have dosemu using 100% CPU all the time; with say
"10" it will still sleep most of the time at the DOS prompt for instance.

Bart

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[jegunn]

On Wed, 17 Nov 2004, Bart Oldeman wrote:

Thanks, Bart. 

The other problem I alluded to still remains. The following line in
.dosemurc

$_X_vesamode = "1024,740"

elicits no response to a query which lists the available VESA modes.
Changing the $_X_vgaemu_memsize has the expected result; going
from one megabyte to 2 brings the 1280x1024 and 1600x1280 modes into
existence, but the custom modes do not show up. This worked fine in
1.0.2.1. Stas suggested that I do some debugging and file a bug report,
which I have not done yet, but there is no debugging output from either
-D9+v or -D9+X.

thanks

--jim

> On Tue, 16 Nov 2004, jegunn wrote:
> 
> > Thanks. I tried this a little while before I got your reply; the
> > performance is *very* sensitive to the setting; 3 is more-or-less
> > OK, but better with zero. I was using 1 before with 1.0.2.1. Did
> > the priority code change between these versions?
> 
> yes, certainly. You may even want to try 1.2.1 and see how that behaves,
> since there were a few changes between 1.2.1 and 1.2.2 that can be
> regressions in certain cases (we'll have to look at this more closely).
> 
> There's a big difference between hogthreshold 1 and 2, then to 3 4 5 etc
> it goes more gradually.
> 
> With "0" you pretty much have dosemu using 100% CPU all the time; with say
> "10" it will still sleep most of the time at the DOS prompt for instance.
> 
> Bart
> 

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[jegunn]

Many apologies--I thought the debugging output came on stdout/stderr, but
it is clearly put into boot.log. Running with -D9+c elicits the output

X_fullscreen 0
vgaemu_memsize 0x600
vesamode_list (nil)
X_lfb 1
X_pm_interface 1

when parsing the .dosemurc lines in the vicinity of

# size (in Kbytes) of the frame buffer for emulated vga. Default: 1024K
                                                                                
$_X_vgaemu_memsize = (1536)
                                                                                
# use linear frame buffer in VESA modes. Default: on
                                                                                
# $_X_lfb = (on)
                                                                                
# use protected mode interface for VESA modes. Default: on
                                                                                
# $_X_pm_interface = (on)
                                                                                
# KeySym name to activate mouse grab, ""=off. Default: "Home" 
(ctrl+alt+home)
                                                                                
# $_X_mgrab_key = "Home"
                                                                                
# List of vesamodes to add. The list has to contain SPACE separated
# "xres,yres" pairs, as follows: "xres,yres ... xres,yres". Default: ""
# for 1024x768 screen use 1024,740 or thereabouts
                                                                                
$_X_vesamode = "1280,960"
#  1280,1024"
                                                                                
# pause xdosemu if it loses focus
                                                                                
# $_X_background_pause = (off)

in .dosemurc. So the memory size is recognized, but the vesamode line is
not. Has the syntax changed? The documentation has not.

thanks

--jim



On Wed, 17 Nov 2004, jegunn wrote:

> On Wed, 17 Nov 2004, Bart Oldeman wrote:
> 
> Thanks, Bart. 
> 
> The other problem I alluded to still remains. The following line in
> .dosemurc
> 
> $_X_vesamode = "1024,740"
> 
> elicits no response to a query which lists the available VESA modes.
> Changing the $_X_vgaemu_memsize has the expected result; going
> from one megabyte to 2 brings the 1280x1024 and 1600x1280 modes into
> existence, but the custom modes do not show up. This worked fine in
> 1.0.2.1. Stas suggested that I do some debugging and file a bug report,
> which I have not done yet, but there is no debugging output from either
> -D9+v or -D9+X.
> 
> thanks
> 
> --jim

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[Bart Oldeman]

On Wed, 17 Nov 2004, jegunn wrote:

> in .dosemurc. So the memory size is recognized, but the vesamode line is
> not. Has the syntax changed? The documentation has not.

No, it's a typo.

in dosemu's etc/global.conf replace
  foreach $yyy ("  ", $X_vesamode)
by
  foreach $yyy ("  ", $_X_vesamode)
recompile and I hope you are all set then.

Bart

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[jegunn]

Thanks much, Bart. I am running from the binary distribution, so I took
the chicken's way out and changed dosemu.users to read the fixed
global.conf file. I will recompile sometime when I have my ducks in a
little better order. Fixed the problem, but made a new one, or at least a
new error message:

quilla:SDSSPrettypics>xdosemu &
[1] 3541
quilla:SDSSPrettypics>ERROR: Unable to open console to evaluate the 
keyboard map.
Please specify your keyboard map explicitly via the $_layout option
ERROR: Unable to open console to evaluate the keyboard map.
Please specify your keyboard map explicitly via the $_layout option
 
I uncommented the $_layout = "auto"

in .dosemurc to no avail, but $_layout = "us" fixed it. Another error 
or version difference between the distributed global.conf and the compiled 
in version? There was no obvious problem with xdosemu (which started
fine), but I thought I should bring it to you attention.

thanks again. This is a *wonderful* piece of code; the old dos cadd
program is the one thing from my Windows/DOS past I simply cannot live 
without, and being able to run it under Linux has been a godsend.

--jim



On Thu, 18 Nov 2004, Bart Oldeman wrote:

> On Wed, 17 Nov 2004, jegunn wrote:
> 
> > in .dosemurc. So the memory size is recognized, but the vesamode line is
> > not. Has the syntax changed? The documentation has not.
> 
> No, it's a typo.
> 
> in dosemu's etc/global.conf replace
>   foreach $yyy ("  ", $X_vesamode)
> by
>   foreach $yyy ("  ", $_X_vesamode)
> recompile and I hope you are all set then.
> 
> Bart
> 

Re: Catastrophic X graphics slowdown going from 1.0.2.1 to 1.2.2.0

[Bart Oldeman]

> Thanks much, Bart. I am running from the binary
> distribution, so I took the chicken's way out and changed
> dosemu.users to read the fixed global.conf file.

Ok, that's fine, it just overrides the builtin one then.

> quilla:SDSSPrettypics>xdosemu &
> [1] 3541
> quilla:SDSSPrettypics>ERROR: Unable to open console to
> evaluate the  keyboard map.
> Please specify your keyboard map explicitly via the
> $_layout option ERROR: Unable to open console to evaluate
> the keyboard map. Please specify your keyboard map
> explicitly via the $_layout option
>
> I uncommented the $_layout = "auto"
>
> in .dosemurc to no avail, but $_layout = "us" fixed it.

$_layout="auto" does not work if you don't have any read
permissions
to the Linux console. Nothing to do with global.conf I see.

This is a known problem (apart from the fact that for remote
X sessions it is wrong to query the console on the remote
machine): in the next version (it's in CVS now)
$_layout="auto" will query the X server about the keyboard
layout so in many cases it will no longer be necessary to
explicitly specify $_layout="us" etc.

Bart