Tk9/NexTk Demo 3 Starkit
George Peter Staplin
I've been doing a lot of work on the Tk9-related code last week. I
finally have something to show for it.
The Starkit includes binaries for NetBSD x86, Linux x86, and Windows
x86.
See some of the changes here, and download the Starkit for Tclkit 8.5a4:
http://wiki.tcl.tk/Tk9
Tclkit 8.5a4 is available from the download matrix here:
http://www.equi4.com/pub/tk/downloads.html
I want to thank everyone that has encouraged me on this project, helped
me with the algorithms, and helped find bugs.
I'll probably be renaming it to NexTk in the future.
I'd also like to point out that Tcl has been so incredibly powerful for
this project. I'm using Tcl to write the core of the entry widget.
proc rendertree which is currently being used to render the various
objects and their children has performed very well. It's performed much
better than I initially thought it would. So even though I'm probably
going to rewrite rendertree in a little C, because it's called so often
and is the major bottleneck at the moment, I'm still amazed how well
pure-Tcl has done.
Enjoy the possibilities!
-George
Robert Hicks
Hey George that looks great. I was wondering if that is to become the
"next" Tk or is it just a "prototype" to try ideas out for the next Tk?
Robert
George Peter Staplin
NexTk was a name proposed by Donal K. Fellows. I like the name. I
think most of the core hasn't really taken me seriously. As I was
building the components for this, and proposed my ideas some of the core
were serious doubters. Some said that Tk9 was essentially what Tile is.
Tk9/NexTk is not just a prototype. I eventually plan to use it for
serious applications. I also want to use it as a replacement for X.
I've done some work on design plans for running it on an Nvidia
framebuffer for my GeForce video card. I have an idea of using a
modified Xvfb X server for X compatibility. If it was just a prototype
I would have given up months ago.
-George
Donal K. Fellows
> Hey George that looks great. I was wondering if that is to become the
> "next" Tk or is it just a "prototype" to try ideas out for the next Tk?
The official TCT line is that there is no Tk 9 at this stage, so I'd
really rather George changed the name of what he's doing to avoid any
future confusion. On the other hand, speaking as a TCT member, I for one
am very interested to watch what George is doing. Will it form the basis
of the real Tk9 when that happens? No idea. :-) But it's certainly grist
for the mill, and the fact that it is an "extended prototype" (i.e. one
that will be used eventually for serious apps) counts very strongly in
its favour. Such work always attracts our support, even if it does not
always result in core changes. After all, it's not at all easy to write
a high-quality library, especially in the GUI space.
*sigh* Computers are so fast these days that doing the sort of graphical
snazziness that George is up to is practical. Such a difference from
when I started using Tk and a redraw could take a fair fraction of a
second... :-)
Donal.
marc spitzer
>
> *sigh* Computers are so fast these days that doing the sort of graphical
> snazziness that George is up to is practical. Such a difference from
> when I started using Tk and a redraw could take a fair fraction of a
> second... :-)
>
> Donal.
But was it "The good old days" or "The bad old days"?
marc
--
ms4...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Uwe Klein
> But was it "The good old days" or "The bad old days"?
>
> marc
>
They morph with temporal distance :
"bad (old) days" ---> "The Good Old Days"
uwe
Donal K. Fellows
> But was it "The good old days" or "The bad old days"?
Bad. I don't like "bisque" very much. ;-)
Donal.
Bryan Oakley
Ahhh... Bisque
(bonus points to those who get the vague reference to an old T.V. show)
Alan Anderson
> Ahhh... Bisque
>
> (bonus points to those who get the vague reference to an old T.V. show)
Tolstoy?
Kevin Kenny
> Bad. I don't like "bisque" very much. ;-)
--
73 de ke9tv/2, Kevin
Andreas Leitgeb
>>> I've been doing a lot of work on the Tk9-related code last week. I
>>> finally have something to show for it.
I wish for YUV (without 2) support. Both my (slightly oldish)
ATI Radeon 7000 and my i865 don't do YUV2, so the latest demo3
failed with some X-protocol error on all machines in my reach.
The previous demo2 worked, though.
George Peter Staplin
That particular error should be fixed in the new Starkit
NexTk_demo5b.kit. It should safely fallback to XShm after
megaimage_frame_platform_init determines that the Xv YUY2 isn't
supported.
Please let me know if it doesn't. You can also disable the XV usage
with an environment variable option that I mentioned on this page:
I'll add YUV soon for you, so that you can have a bit more speed, but my
video card only supports the following YUV-based formats (according to
xvinfo), so I would need your help testing it.
Number of image formats: 4
id: 0x32595559 (YUY2)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (YV12)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x59565955 (UYVY)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x30323449 (I420)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
Ideally, eventually I'll have support for all of the common video card
formats, and everyone can benefit from the acceleration.
Also, if any of you know about PCI or AGP bus programming and can
suggest some books or would answer some newbie questions regarding video
card setup I'd appreciate it. I want to port this to my nvidia card in
NetBSD and other systems and cards as a replacement window system.
-George
Andreas Leitgeb
> That particular error should be fixed in the new Starkit
> NexTk_demo5b.kit. It should safely fallback to XShm after
> megaimage_frame_platform_init determines that the Xv YUY2 isn't
> supported.
Starting demo5b now showed just a pitchblack window,
Although all the buttons are there, because depending
on the position of blind clicks, I sometimes get a
"Hello" on the console, or the application exits.
Starting it with the named Env-variable, I finally
had a chance to see it.
I guess this is not yet the time to complain about
the edit-control not behaving like tk's entry (e.g.
selecting text with shift-cursorkeys, displaying non-
latin characters (I tried greek ones, and they showed
up as accented latin characters) So just that
I'm mentioning it shouldn't be mistaken for a complaint :-)
Also, I found it funny, that once you rotate a button
by 180 degs, it appears sunken :-) While rotating it
right-click by right-click I wasn't able to tell at
which angles the buttons started to visually stick
in and out. - Of course this is not a bug in the
prog, but a "feature" of human 3d-imagination.
> I'll add YUV soon for you, so that you can have a bit more speed, but my
> video card only supports the following YUV-based formats (according to
> xvinfo), so I would need your help testing it.
ok, looks like I fell for my own ignorance of Xv:
my xvinfo shows *exactly* (really; I used tkdiff)
the same four formats, (though in a different
ordering: YUV2,UYVY,YV12,I420)
It was the line starting with "type:" in each block
that I misread as "my card only does YUV".
Tell me what other data would be relevant.
The complete xvinfo-output on this machine can be
seen on: <http://www.logic.at/people/avl/stuff/xvi>
George Peter Staplin
> George Peter Staplin <geor...@xmission.com> wrote:
>> That particular error should be fixed in the new Starkit
>> NexTk_demo5b.kit. It should safely fallback to XShm after
>> megaimage_frame_platform_init determines that the Xv YUY2 isn't
>> supported.
>
> Starting demo5b now showed just a pitchblack window,
> Although all the buttons are there, because depending
> on the position of blind clicks, I sometimes get a
> "Hello" on the console, or the application exits.
I'll have to think about this more... I have a feeling that the
XPutImage path is so slow that the idle events never occur. I've run
into this behavior before. Alas, that might require the equivalent of
update idletasks in the form of Tcl_DoOneEvent to get redraws in the
NexTk host widget to work in the XPutImage path only.
> Starting it with the named Env-variable, I finally
> had a chance to see it.
>
> I guess this is not yet the time to complain about
> the edit-control not behaving like tk's entry (e.g.
> selecting text with shift-cursorkeys, displaying non-
> latin characters (I tried greek ones, and they showed
> up as accented latin characters) So just that
> I'm mentioning it shouldn't be mistaken for a complaint :-)
The entry widget needs a lot more work. It's only about 2 days of work
old. You may be amazed by how little Tcl code it takes to implement it.
The button, entry, and clock are all Tcl, even the grid manager is Tcl.
> Also, I found it funny, that once you rotate a button
> by 180 degs, it appears sunken :-) While rotating it
> right-click by right-click I wasn't able to tell at
> which angles the buttons started to visually stick
> in and out. - Of course this is not a bug in the
> prog, but a "feature" of human 3d-imagination.
>
>> I'll add YUV soon for you, so that you can have a bit more speed, but my
>> video card only supports the following YUV-based formats (according to
>> xvinfo), so I would need your help testing it.
>
> ok, looks like I fell for my own ignorance of Xv:
> my xvinfo shows *exactly* (really; I used tkdiff)
> the same four formats, (though in a different
> ordering: YUV2,UYVY,YV12,I420)
>
> It was the line starting with "type:" in each block
> that I misread as "my card only does YUV".
>
> Tell me what other data would be relevant.
> The complete xvinfo-output on this machine can be
> seen on: <http://www.logic.at/people/avl/stuff/xvi>
Thank you :)
Are you out of shared memory, or do you have SysV-style shared memory
enabled? You can check if something has left unreleased memory with the
/usr/bin/ipcs program.
I have sometimes created program faults that result in retention of the
shared memory after the app exits, so I wrote a little script called
rmshm to free it. Eventually I need to add a signal handler with
siglongjmp, so that if an app exits due to a fault, shared segments are
automatically cleaned up. The problem I have with that is that the
user's application may require signal handling, and I'm not sure what to
do for that case.
$ cat /gps/bin/rmshm
#!/usr/bin/env tclsh8.4
catch {exec ipcs -m} data
foreach word [split $data] {
if {[string is integer -strict $word]} {
catch {exec ipcrm -m $word}
}
}
It works in NetBSD, and it seems that active processes retain some
reference to the shared memory structures. So it doesn't cause any
problems with applications that still require shared memory, when I free
the shared memory. They remain in the ipcs list after the rmshm.
Do mplayer and/or xine work with Xv on your system?
Could you try this little program on your system (it displays RGB
stripes):
http://www.xmission.com/~georgeps/engineering/prototype/Xv_prototype-8.tar.bz2
That may provide more debugging output that would be useful.
Thanks again,
George
Andreas Leitgeb
> Are you out of shared memory, or do you have SysV-style shared memory
> enabled? You can check if something has left unreleased memory with the
> /usr/bin/ipcs program.
Indeed there are a couple (about 15) shared memory chunks
listed by ipcs. Anyway, I don't know and can't tell if these aren't
needed e.g. by currently running browsers/plugins, or X-clients
using the sharedmem-extension, or whatever.
Anyway, I wouldn't dare to call ipcrm on everything that looks
like a number in the output of ipcs (as implemented in the script)
Next week I'm guing on vacation and turn off the machine, so
all sharedmem regions will be freed after vacation, anyway.
Inhowfar are these sharedmems connected to Xv, anyway?
Just that they are left behind by stalling apps, or also
in some way that might cause stall of other apps?
> It works in NetBSD, and it seems that active processes retain some
> reference to the shared memory structures. So it doesn't cause any
> problems with applications that still require shared memory, when I free
> the shared memory. They remain in the ipcs list after the rmshm.
But shared mem is designed to survive program exits.
Some programs might want to get back to it later.
> Do mplayer and/or xine work with Xv on your system?
Yes, mplayer works well with Xv on this machine.
(on another, the one with i865-graphics, it failed when
playing an about-1024x768-sized video over Xv for memory
reasons - only played it after disabling Xv with -vo x11)
I hardly ever use xine, but it works, too.
> Could you try this little program on your system (it displays RGB
> stripes):
> http://www.xmission.com/~georgeps/engineering/prototype/Xv_prototype-8.tar.bz2
I will, but I can't promise if I'll be able to do it till
tomorrow or even this week...
PS: quite an avian look you have according to frappr -
how does one type with wings? :-))))
George Peter Staplin
> George Peter Staplin <geor...@xmission.com> wrote:
>> Are you out of shared memory, or do you have SysV-style shared memory
>> enabled? You can check if something has left unreleased memory with the
>> /usr/bin/ipcs program.
>
> Indeed there are a couple (about 15) shared memory chunks
> listed by ipcs. Anyway, I don't know and can't tell if these aren't
> needed e.g. by currently running browsers/plugins, or X-clients
> using the sharedmem-extension, or whatever.
> Anyway, I wouldn't dare to call ipcrm on everything that looks
> like a number in the output of ipcs (as implemented in the script)
Well it works in NetBSD without harm. I'm not sure how other SysV
shared memory is implemented. I am the only user on my machine though,
and I'm not starting or restarting daemons/apps at the time.
> Next week I'm guing on vacation and turn off the machine, so
> all sharedmem regions will be freed after vacation, anyway.
>
> Inhowfar are these sharedmems connected to Xv, anyway?
> Just that they are left behind by stalling apps, or also
> in some way that might cause stall of other apps?
XShm and Xv generally use shared memory for transport of graphics to the
X server over the localhost. This is much faster.
Xv takes:
35691 microseconds
XShm is a little slower, but not by much.
XPutImage takes:
~530000
The XPutImage speed also fluctuates over a greater range. The Tk 8.4
photo uses XPutImage. XPutImage and XGetImage (for COMPLEX_ALPHA) are
the most costly places in photo, according to my profile results. I
spent some time trying to speed up photo before I gave up and just wrote
my own thing.
The pattern is something like this for shared memory:
1. The megaimage_frame client requests to create an XShmImage or
XvImage (with XvShmCreateImage).
2. memory is allocated that fits the size of the image for the
dimensions ximg->bytes_per_line * ximg->height, shmget()/shmat().
3. The shared memory info structure for X is transferred over the
network code, via XShmAttach() and then X is able to use it when a put
image operation occurs.
4. RGBA data is then reordered or dithered in one of these:
csrc/megaimagetk/x/megaimage_frame_xv_rgb_to_yuy2.c or
csrc/megaimagetk/x/megaimage_frame_xshm_ditherimage.c or
5. XShmPutImage() or XvShmPutImage() transfer the drawing to the
display.
If the persistent flag is enabled for a megaimage.frame then the shared
memory and XShmImage or XvImage are retained between calls, so long as
the width and height don't change of the image. In the persistent case
it only releases the shared memory when the widget is destroyed. This
sort of cries out for an atexit() handler that iterates a list or
something like that I guess in the Megaimagetk_Init function to detach
and IPC_RMID.
I've often wished that X would provide a generic layer for all of this,
but as the saying goes "If the designers of X-Windows built cars, there
would be no fewer than five steering wheels hidden about the cockpit,
none of which followed the same principles -- but you'd be able to shift
gears with your car stereo. Useful feature, that."
- Marus J. Ranum, Digital Equipment Corporation
>> It works in NetBSD, and it seems that active processes retain some
>> reference to the shared memory structures. So it doesn't cause any
>> problems with applications that still require shared memory, when I free
>> the shared memory. They remain in the ipcs list after the rmshm.
>
> But shared mem is designed to survive program exits.
> Some programs might want to get back to it later.
True. I haven't had that problem.
>> Do mplayer and/or xine work with Xv on your system?
>
> Yes, mplayer works well with Xv on this machine.
> (on another, the one with i865-graphics, it failed when
> playing an about-1024x768-sized video over Xv for memory
> reasons - only played it after disabling Xv with -vo x11)
> I hardly ever use xine, but it works, too.
Interesting. It seems it's a good thing I added the environment
variable option.
>> Could you try this little program on your system (it displays RGB
>> stripes):
>> http://www.xmission.com/~georgeps/engineering/prototype/Xv_prototype-8.tar.bz2
>
> I will, but I can't promise if I'll be able to do it till
> tomorrow or even this week...
OK. Thank you for the followups :)
>
> PS: quite an avian look you have according to frappr -
> how does one type with wings? :-))))
hehehe That was my brother's old cockatiel. He ended up flying away to
some place in Utah, never to be seen again by my brother. I miss the
little creature. His name was Clowny.
-George
Andreas Leitgeb
> Xv takes: 35691 microseconds
> XShm is a little slower, but not by much.
> XPutImage takes: ~530000
> If the persistent flag is enabled for a megaimage.frame then the shared
> memory and XShmImage or XvImage are retained between calls, so long as
> the width and height don't change of the image. In the persistent case
> it only releases the shared memory when the widget is destroyed. This
> sort of cries out for an atexit() handler that iterates a list or
> something like that I guess in the Megaimagetk_Init function to detach
> and IPC_RMID.
I'm not sure if I understand correctly, but if an application stalls
then it likely will not call atexit(). On the other hand, if the
application dies, so does the connection to the Xserver, and the
XServer should then clean up all the shared memory that it has
shared with that particular client.
>>> Do mplayer and/or xine work with Xv on your system?
>> Yes, mplayer works well with Xv on this machine.
>> (on another, the one with i865-graphics, it failed when
>> playing an about-1024x768-sized video over Xv for memory
>> reasons - only played it after disabling Xv with -vo x11)
>> I hardly ever use xine, but it works, too.
> Interesting. It seems it's a good thing I added the environment
> variable option.
Seems so, at least until the automatic fallback works even after
an BadAlloc has occurred.
>>> Could you try this little program on your system (it displays RGB
>>> stripes):
>>> http://www.xmission.com/~georgeps/engineering/prototype/Xv_prototype-8.tar.bz2
I got to test it, and even on two machines.
machine 1: furtheron referred to as "work"
some badly supported SiS-chipset and disabled onboard graphics,
added AGP-card: ATI Radeon 7000
Result:
I see a black window with two green (co-centric) rectangles.
No color-stripes
machine 2: furtheron referred to as "home"
i865 onboard graphics (the one where mplayer playing
the hi-res video failed with a "BadAlloc")
Result:
I did see the RGB-stripes (and the green rectangles) all fine.
(at some point later a machine 3 may come into play as "home2",
which is an old AMD 1.2GHz with also an ATI Radeon 7000,
but its only rarely turned on, and I don't have any logs
from that machine at the moment)
The visible output of your program was exactly the same among
home and work, (although the visible effect certainly wasn't)
It was:
numAdaptors 1
0x32595559 YUY2 packed
y_sample_bits 8 u_sample_bits 8 v_sample_bits 8
component_order YUYV
500000
width * height * 2 500000
Redrawing from Expose.
The rectangles move along with the window (when I move that)
however the stripes were stuck on screen, and were fitted
to window only when soem part of the window became unobscured
and the message "Redrawing from Expose." appeared. But I guess
this is normal Xv-behaviour, and your test-prog doesn't handle
window-moves.
I replaced the xvi-file on my website by two xvi-home, xvi-work
on <http://www.logic.at/people/avl/stuff/>
George Peter Staplin
> George Peter Staplin <geor...@xmission.com> wrote:
>> Xv takes: 35691 microseconds
>> XShm is a little slower, but not by much.
>> XPutImage takes: ~530000
> yes, that surely *is* a difference...
>
>> If the persistent flag is enabled for a megaimage.frame then the shared
>> memory and XShmImage or XvImage are retained between calls, so long as
>> the width and height don't change of the image. In the persistent case
>> it only releases the shared memory when the widget is destroyed. This
>> sort of cries out for an atexit() handler that iterates a list or
>> something like that I guess in the Megaimagetk_Init function to detach
>> and IPC_RMID.
>
> I'm not sure if I understand correctly, but if an application stalls
> then it likely will not call atexit(). On the other hand, if the
> application dies, so does the connection to the Xserver, and the
> XServer should then clean up all the shared memory that it has
> shared with that particular client.
You are correct about exit, however if the application exits I don't get
a DestroyNotify event, and the retained memory stays around :)
The Xserver doesn't ever call shmget or shmctl with IPC_RMID, so it
doesn't cleanup the shared memory. The Xserver only calls shmat, shmdt,
and "shmctl(stuff->shmid, IPC_STAT, &buf))."
>>>> Do mplayer and/or xine work with Xv on your system?
>>> Yes, mplayer works well with Xv on this machine.
>>> (on another, the one with i865-graphics, it failed when
>>> playing an about-1024x768-sized video over Xv for memory
>>> reasons - only played it after disabling Xv with -vo x11)
>>> I hardly ever use xine, but it works, too.
>
>> Interesting. It seems it's a good thing I added the environment
>> variable option.
> Seems so, at least until the automatic fallback works even after
> an BadAlloc has occurred.
I'm checking for BadAlloc, so it must be something else. Here's a chunk
of my code:
f->shminfo.shmid = shmget (IPC_PRIVATE, f->xv.image->data_size,
(IPC_CREAT | 0777));
if (f->shminfo.shmid < 0) {
perror ("shmget");
XFree (f->xv.image);
f->xv.image = NULL;
return 0;
}
f->shminfo.shmaddr = shmat (f->shminfo.shmid, NULL, 0);
if ((char *)-1 == f->shminfo.shmaddr) {
perror ("shmat");
XFree (f->xv.image);
f->xv.image = NULL;
shmctl (f->shminfo.shmid, IPC_RMID, 0);
return 0;
}
f->shminfo.readOnly = 0;
f->xv.image->data = f->shminfo.shmaddr;
XShmAttach (f->display, &f->shminfo);
The permissions are supposed to be 0777 based on the tutorial that came
with XFree86, because the client and Xserver may run as different users.
This is good to know. Thank you for testing it.
> The rectangles move along with the window (when I move that)
> however the stripes were stuck on screen, and were fitted
> to window only when soem part of the window became unobscured
> and the message "Redrawing from Expose." appeared. But I guess
> this is normal Xv-behaviour, and your test-prog doesn't handle
> window-moves.
That's normal behaviour in the test program.
> I replaced the xvi-file on my website by two xvi-home, xvi-work
> on <http://www.logic.at/people/avl/stuff/>
Upon examination of that, the only thing that jumps out at me is:
"XV_SET_DEFAULTS." Your card may need that set. I'm going to
search for this at Koders.com and see what others are doing about it.
It does explain why the card doesn't work in mplayer. I suspect other
bugs in the mplayer implementation of vo_xv.c too, based on my review of
it.
Thank you,
George