Xfbdev and CTRL-ALT-M notes

[PDP-8]

Running with the stock Xfbdev with TCpure64 ver 10 by choice, rather than Xorg.

I'm on the hunt to make Xfbdev a little faster, so just gathering observations for now.

Noticed that when using ctrl-alt-m to resize a window, it is very snappy and fast *IF* you don't move the application window away from it's initial geometry.

If you do move the window away from it's default, ctrl-alt-m is a bit slower.

At first I thought this initial geometry was tied to an upper left 0,0 coordinate, but if you pull up the mount tool, which does not have an upper left 0,0 geometry coordinate, the results are the same: snappy with ctrl-alt-m from default, but once moved, you can see the redraw slowing with ctrl-alt-m.  Not that you want to use the mount tool full screen.

How to test:  instead of tapping ctrl-alt-m, hold it down which will just repetetively go full screen and back as fast as it can.

There seems to be some sort of redraw interaction that might possibly lie with FLTK/flwm, or perhaps possibly even the mouse settings.

The system is very usable as is, and of course changing to xorg changes things, but I'm sticking to Xfbdev for now.  I'm on the hunt.....

[jazzbiker]

Hi, PDP-8!

Interesting observations. I've checked and can approve your guess, that window positioned at 0,0 is maximizing much faster, than non-cornered one. But as i use Core on very slow box (compared with modern hardware, its lightning fast for me, my memory isn't damaged yet and keeps some reminiscences of 80386, 80286, 8086 and, yes, PDP-11, even soviet MIR-1 computer with 16K RAM cube of ferrite cores) - Atom Z520 - i must say that Mounttool behaviour is the same, faster a little but the same, i see it on my box.
So when you call maximize cornered window is spread on the whole screen immediately. And if window is uncornered, it is first moved to 0,0 corner (i see it) and then spread around. And during size restore all is taken the reverse order - squeezing to the 0,0 corner and then moving to original position.
Seems that moving window takes more time than spreading it over full screen.

I like Xfbdev too! I am TinyCore addict and as every addict don't want to be treated )

There are some issues with ctrl-alt-V and ctrl-alt-H, if you are interested i can describe them.

[PDP-8]

Found a neat trick!

I'm not pushing anything major - just a couple of rxvt's, ttf fonts, native res, and some .Xdefault tweaks.  Maybe look at some static jpg's and whatnot - but I'm amazed at how good that can look for this use case.

Check this out - found another spot where fullscreen ctrl-alt-m is fast and snappy: The bottom left corner too, but there's a catch with a solution..

If you don't move say a terminal away from the upper left corner, ctrl-alt-m is snappy.  But if you move it away from that position, and try to put it back to the upper left corner via the mouse, it won't be snappy anymore.

SOLUTION:  walk it in with the fltk-keybindings (ctrl-alt <arrow keys>)

Now your fullscreen will be snappy again.  I guess the keybindings provide the resolution precision to make this work.

Apply this same trick if you want to use the bottom left corner too!  Get close with the mouse, and then walk it in - even if you *think* you have it moused in perfectly.

TWO terminals: one upper left, and one bottom left.  Here's how:

Fire up two terminals.  The first one flies to the upper left.  The second one is offset, and ctrl-alt-m fullscreen is a bit draggy.

Just move that second terminal close to the bottom left, and then walk it into that corner with ctrl-alt <arrow keys>.

You can now make either terminal active, and perform a snappy fullscreen on either one.

If that's the price to pay, that just might work well enough for me...
 

[PDP-8]

Just a reminder - thanks to Juanito's tip about running UEFI with Xfbdev for a major speedup ..

On one of my modern mini-pc's, I can turn OFF CSM completely in the bios and use UEFI only.  Other than possibly disabling secure-boot it is kind of backwards to what we strive for.   But it certainly does make Xfbdev run MUCH faster.

However, on that one strange mini-pc, one of the bios defaults tucks away a video setting to use "legacy" video by default!  Even if I have disabled CSM.  Once I found that little bugger, I *forced* it to use UEFI for video, and tada!

Modern hardware, and TCpure64 - gotta' love it!

[PDP-8]

Easier way to get Two terminals up and anchored in the upper left and lower left corners for zippy ctrl-alt-m fullscreens:

1) Fire up a terminal.
2) Extend it horizontally ctrl-alt-h
3) Fire up your second terminal

Step 2 makes the second terminal session anchor to the lower left, rather than being offset.

If either one shows too much sluggishness, try walking them off and walking them back to the corners with ctrl-alt-<arrow keys> even if they look ok.

Strange fun....

[labeas]

> There are some issues with ctrl-alt-V and ctrl-alt-H, if you are
>   interested i can describe them..
Where's the man/info about ctrl-alt-M,V,H ?

> then walk it into that corner with ctrl-alt <arrow keys>.
Yes, that's good. Where's it documented ?

> Just a reminder - thanks to Juanito's tip about running UEFI
> with Xfbdev for a major speedup ..
This new/cheap laptop, which I finally got to follow our

<how2 UEFI with grub2> thread: has abnormal delays of MINUTES
when I step thru the bootup stages. What could cause that?

> 2) Extend it horizontally ctrl-alt-h
OK: that sumarrises/documents the M,V,H parameters.

[PDP-8]

Where's the man/info about ctrl-alt-M,V,H ?

It's part of the flwm.tcz.info file.  You can see this in appbrowser if you click on the flwm.tcz file as if you were going to install it.  The info shows up in the right hand pane.

Took me awhile back to see it, since when I started with tinycore, I didn't need to load flwm manually - it was already there.  So I started browsing as if I was going to install it, and tada!  There it was.

Here are the relevant comments from 8.2 - always good to look at the latest just in case anything changed however:

Code: [Select]

Comments:       For microcore, as found in tinycore v2.4
                Thanks to Mike L. For the many improvements to flwm.
changed Alt+Enter to Alt+F1 to iconize a window
Ctrl Alt arrows moves the window
Ctrl Alt =         grows the window (unshifted + key)
Ctrl Alt -          shrinks the window
Ctrl Alt PgUp   grows the window veritcally
Ctrl Alt PgDn   shrinks the window vertically
Ctrl Alt ,           grows the window hortizontally (unshifted < key)
Ctrl Alt .           grows the window hortizontally (unshifted > key)
Ctrl Alt t           taller (sames as PgUp)
Ctrl Alt s          shorter (same as PgDn)
Ctrl Alt m          maximize widow
Ctrl Alt v          maximize vertical
Ctrl Alt h          maximize hortizontal
flwm now optionally supports environment variable FLWM_TITLEBAR_COLOR to set color for window title bars.
To set use hex rgb, e.g, 20:5F:20 (Currently supports fltk gtk+ scheme.)
If I hadn't seen that, I wouldn't have easily figured out how to change titlebar colors either.

<how2 UEFI with grub2> thread: has abnormal delays of MINUTES
when I step thru the bootup stages. What could cause that?

Sorry - no idea.  Maybe an unusually long waitusb parameter?  Don't know..