According to some of the (printed) documentation I have here, the --target
option should be used when "you want to build a cross compilation
tool" (e.g. a cross-compiler etc.).
However, when you want to build code that should run on the system (even a
library), the --host and --build option appea
On Tue, 14 Aug 2001, Brian S. Julin wrote:
> Obstacle #4: Failure to deliver hardware acceleration. Other graphics
> packages are currently providing much more hardware acceleration
> support than LibGGI.
>
[...]
> Obstacle #4 has a simple solution: encourage KGI development, and in
> the mea
On Thu, 16 Aug 2001, Brian S. Julin wrote:
> On Fri, 17 Aug 2001, Rodolphe Ortalo wrote:
> > I think I'll soon need a place within LibGGI (and possibly its
> > extensions) to plug kgi-matrox specific code. Note also that the
> > 3Dlabs/PERMEDIA driver is even more r
On Mon, 27 Aug 2001, Andreas Beck wrote:
[...]
> However there was something like this there somewhen as well. However I
> don't quite remember how it was called.
libgwt ?
R.O.
Hello,
I've been playing for a few weeks with the WARP accelerator(s) engine of
the G400 (3D setup + 2D raster engine) on a KGI-enabled kernel. Up to now
I've postponed an actual drawing weirdness problem (because I had lower
level issues to tackle first ;-) but now I'm adressing it and... well..
Well, sorry for bothering everyone on this but... it seems setting a
linear LUT for the ramdac palette helps a lot... It was not 3D problem
(16bpp is palettized in fact - I had forgotten that.)
Still, I'd be happy to have some "standard" 3D test programs and models.
Rodolphe
On Fri, 12 Oct 2001, Christoph Egger wrote:
[...]
> I got more and more mails from users, who are crying for [...]
> accelerated extension-targets
[...]
I am currently working on userspace code for sending accelerated commands
to the KGI Matrox driver, following pretty closely the LibGGI API. I
On Sat, 13 Oct 2001, Brian S. Julin wrote:
[...]
> Once these are complete most hurdles will have been cleared and the
> rest is just a flesh-out operation. Until then, I do not feel confident
> opening the book on 3D.
I do agree with you. We may open the book for 3d right now [1], but it's
pro
On Mon, 15 Oct 2001, Brian S. Julin wrote:
[...]
> > [2] E.g.: texture allocation deserves to be done cleanly
>
> Here you hit the nail on the head.
Yep, allocation is a very annoying issue when you want to manage all the
details (pitch != width, and the like).
[...]
> Hopefully we can finis
On Tue, 16 Oct 2001, Brian S. Julin wrote:
> On Tue, 16 Oct 2001, Rodolphe Ortalo wrote:
> > That's pretty much "sidestepping the problem" as you say - but I'm still
> > wondering if a general algorithm has been published to address the problem
> > of
On Tue, 19 Mar 2002, Brian S. Julin wrote:
[...]
>
> KGI directories other than libkgi should be moved to an attic, IMO,
> Since they cannot drive the current KGI. libkgi is the playground.
>From what I've read in ggi-core/libggi/display/libkgi/ and
ggi-core/libggi/include/ggi/display/libkgi.
[ This mail is even longer than Brian's... You've been warned. ;-) ]
Hi Brian,
overall I really understand your point, and you are right on many aspects,
including the fact that no "rush" is needed, and that some more design
work (or discussion) would be useful to KGI as a project (as useful as
Well, it seems I should give it a try to all this now... I'll have
look a display/kgi/ and we'll see...
On Fri, 22 Mar 2002, Brian S. Julin wrote:
> On Fri, 22 Mar 2002, Rodolphe Ortalo wrote:
> > Concerning 1) I guess this is because you think the mmap()-trick
> > and
I hope I can be there on Saturday.
Btw, at which hour is the meeting in France? It's 1pm eastern time, so
19:00 GMT? isn'it? Isn't it 7 or 8pm in France? Hmmm I'm not sure I can be
there at that time (a 2-years-old boy that wants dinner is a pretty
high-level interrupt - even with power-switch s
Hello,
When trying to compile libggi & libgii (a CVS version from Wednesday IIRC)
--with-kii I have a few problems.
Up to now, I've been obliged to apply a few fixes to "kii.h" (see diff)
and I'm wondering if there are correct. And as
should be included by kii.h, I now have the following error:
On Sat, 30 Nov 2002, Christoph Egger wrote:
> I just tried KGI, too.
[...]
> Please update from CVS again.
Done. libgii built fine wrt kii/kgi now. Thanks.
libggi compiled *nearly* fine, however, libggi configure.in does a
AC_CHECK_HEADER(kgi/kgi.h, ... ) in addition of the AC_TRY_COMPILE(..).
Hi,
so, I made some new attempts, and here are my results with the Matrox
driver.
Indeed, the monitor error was simply a non-working mode (I used the SVGA
monitor). Doing:
export GGI_DEFMODE="1024x768x16"
(for example, "800x600x16" works too) solved most problems with fb setup.
So, yes, I defin
On Sat, 30 Nov 2002, Rodolphe Ortalo wrote:
> I'm going to commit my changes to the Matrox driver in kgi-wip today. I
> think it's good enough for testing.
Commit done to kgi-wip now.
Rodolphe
> PS: Note that "flying_ggis" on the G200 and simultaneously "
[GGI folks may be interested by 2) below.]
On Mon, 2 Dec 2002, Filip Spacek wrote:
[...]
Thanks for the details.
> So to answer your question: it depends on the number of focuses you have
> (which is equal to the number of keyboards)
>
> I usually replace display 0 with my driver (since I have
On Wed, 4 Dec 2002, Christoph Egger wrote:
> Please test them out and give us feedback on IRC [1] or here on this list.
I've just rebuilt with from a fresh CVS update.
> Changes from libgii 0.8.2-rc3 to libgii 0.8.2-rc4:
>
> - minor kii input update
I had to apply the one line patch at the e
Hello,
attached is a patch that solves - at least for me - some of the input
problems that I experienced with libgii on KII. I think the fix sounds
reasonable, and it is just a re-import of some of the other input targets
(I looked at linux_kbd for comparison for example).
Please commit if you fi
Hello,
I updated from CVS tonight and still have a problem building the kgi
target with the current configure.in.
The check for header kgi/kgi.h does not take into account the fact that
this header wants, for example, HOST_OS to be defined. If it is not, the
header fails to read (#error) and the
Hello,
is the plane_mask entry of the ggi_gc struct really used (see
ggi/internal/structs.h)?
There is not "update mask" associated with this field of the struct (on
the contrary of the foreground/background color or clip coordinates), so
I'm wondering if I should or should not overwrite the PLNW
Hello,
once again, I think I hit the problem of synchronizing the accelerator
drawings and the drawings made directly in the framebuffer by
(unaccelerated) drawing operations.
It seems there is a provision for such synchro in ggi_visual (especially
with the fields needidleaccel and accelactive).
On Sun, 15 Dec 2002, Brian S. Julin wrote:
> vis->opdisplay->idleaccel should be loaded with your target's
> accelerator idling funtion.
>
> When a mode is set, the target is supposed to set vis->needidleaccel
> if it wants the stubs renderer to provide accelerator-friendly pixel
> functions.
On Tue, 17 Dec 2002, Andreas Beck wrote:
> When GGI was you, graphics on Linux was something exciting, new. And
> hardware wasn't that overly powerful, that you could just take some
> strange highlevel toolkit, drop in a scenery and get a 3D rendering
> from it. in realtime, just because the ha
On Sun, 15 Dec 2002, Brian S. Julin wrote:
[...]
> A sublib that has the need for idling the accelerator should provide
> at least hline, vline, box; e.g. it should not leave solid-fill
> primitives to the generic renderers, because the generic libs only
> contain "accelerator aware" versions of
On Tue, 17 Dec 2002, Filip Spacek wrote:
[...]
> Yes! These are exactly my dreams for the (near) future of libggi.
>
> What I think is needed is a more evolved concept of a subvisual. The
> current one can only be used to create a rectangular viewport on an
> existing visual is unfortunately ins
On Wed, 18 Dec 2002, Andreas Beck wrote:
> > Which widget library? Some of your own or something more general?
>
> One of my own. Basically something to do away with an ugly TCL/Tk
> script that is used to control eccet. The idea is to have something that
> can nicely live side by side with o
On Sun, 15 Dec 2002, Paul Redmond wrote:
[...]
> http://www.student.math.uwaterloo.ca/~pmredmon/ggibench.c [on KGI?]
[...]
Here is the output up to now (K6-III 450MHz, G200 AGP):
identified to mapper graphic-0.9.0-0
1024x768 (1024x768)
1024x768 (1024x768)
ggiDrawPixel: 333598 pixels/second
On Thu, 19 Dec 2002, Brian S. Julin wrote:
>
> On Tue, 17 Dec 2002, Rodolphe Ortalo wrote:
> > Is it also the case for putc, puts (and possibly copybox)? I have some
> > strange output with them.
>
> If the put* functions are implemented in software, yes, and indeed
&g
On Thu, 19 Dec 2002, Andreas Beck wrote:
> > 1- For precise interface layout, I do not want to program: I simply want
> > an UI builder. I do *not* care of the actual API involved below, I do not
> > want to be able to call it directly. I want these damns buttons to get
> > drawn, I do not want
On Thu, 19 Dec 2002, Andreas Beck wrote:
> Not bad. On (unaccelerated) XGGI on fbdev I get at 1024x768x24 (running
> on 1600x1200 - i.e. high VideoOut Memory bandwidth demands) on a PIII/800
Oops, sorry. I was running at 1024x768x16 (not 24). Should have indicated
this. I cannot set 24 or 32 m
On Thu, 19 Dec 2002, Stefan Seefeld wrote:
> I don't think an interactive GUI builder is an absolute must to get a
> GUI,
[...]
I really think it is a very important point to get _applications_ using a
GUI. I'd even say that it should be a requirement.
But I understand that you may also have a
On Thu, 19 Dec 2002, Paul Redmond wrote:
> Yeah, the KGI Radeon accelerator is PIO only. Once DMA'd ring buffers are
> implemented it will fly!
It will not necessarily be so much faster, it may be your system CPU load
that drops. Anyway, that's free horsepower to do more beautiful or more
accu
Hello,
what's the format of the 8x8 font available via ggi/internal/font/8x8 ?
I guess it probably is a standard font, but I'm trying to use it as a
pattern base for drawing with the G200 accel and... well, for the moment
it looks like some bizarre runic alphabet... :-) Could possibly explain me
Hello,
here is some corrected output for G200 hardware with:
- hw accel for Putc with the simple 8x8 fixed width font (and also
copybox, but it is not tested there...)
- some personal updates to the KGI target to have it load pixela
directbuffer functions (those that sync with an hw accelerator)
Hello,
I've just committed a new default/kgi/Matrox/ directory with some *.c in
it. The kgi-Gx00 sublib now provides acceleration for some of libggi
drawing functions (drawbox, line, hline, vline, putc). It should also
accelerate copybox (but I am not totally sure that the implementation is
correc
On Mon, 23 Dec 2002, Aurelien Reynaud wrote:
>
> Hi, I am a longtime lurker on the GGI mailing list...
>
> I'm not so good at programming and do not have much time either, but I'd be
> glad to help. So I can answer yes to your question: I have an old Mystique
> lying around. Maybe I can make so
On Mon, 23 Dec 2002, Brian S. Julin wrote:
> On Mon, 23 Dec 2002, Rodolphe Ortalo wrote:
> > 0) What should a KGI-accel-oriented developper do next? :-)
>
> I'd like to see the get/put issues worked out personally, and of
> course, whatever can be done to bring the acc
On Thu, 26 Dec 2002, Christoph Egger wrote:
[...]
> And OUR ANNOUNCEMENT IS ON THE FRONT PAGE
[...]
Congratulations to the author(s) then! (It was rather well written.)
Rodolphe
Meilleurs voeux et bonne annee a tous.
Rodolphe
Hello,
there is a problem with the G400 and the version of the Matrox Gx00 accel
sublib for KGI in the CVS tree right now. "copybox" is erroneous and
freezes the target display. The computer is still usable, but the
associated head is... problematic to use (unless you love to work in text
mode whi
Hello,
I've corrected the copybox bug in the Matrox libggi KGI accel sublib. It's
not a definitive fix but it solves that problem. The correction is in CVS.
However, further testing with libggi and my G400 showed another problem:
sometimes, a drawing engine infinite loop is detected by the driver
I just start now in this heated discussion.
Apparently, there are several subjects:
1) Whether generic backbuffering is desirable or not in general;
2) Whether it is possible to implement such a backbuffering mechanisms in
a safe way on current hardware.
As to 1), I guess this is primarily an a
On Tue, 21 Jan 2003, Fabio Alemagna wrote:
[...]
> > You miss, that in X, you never talk to the graphics HW directly. X will
> > send you an event when you iconify, and will nicely gobble up all
> > your funny drawing requests if you don't act on it.
>
> Not completely true: if backing store is
On Tue, 21 Jan 2003, Jos Hulzink wrote:
> And, let's face it: For which programs would a background framebuffer be
> useful and worth the trouble ? For programs that can't refresh within
> #include GGI_SMALL_AMOUNT_OF_TIME.
I'd rather say "the impatient user". :-) I really like the idea of
And
On Tue, 21 Jan 2003, Andreas Beck wrote:
> Thus I pledge for the following:
>
> 1. Signal the app for switchaway.
>
> 2. Let the app do whatever it thinks is reasonable to get ready for that
> to happen. Here the app can just ggiOpen a memvisual and the ggiCrossBlit to
> it, swap visuals and b
On Wed, 22 Jan 2003, Fabio Alemagna wrote:
[...]
> only platform), and also because there exist one free alternative to
> AmigaOS, which is AROS, and another commercial alternative which is
> MorphOS, and everyone of dem deals perfectly with the issue we're
> discussing here. I'll explain in anot
Rubén wrote:
> The virge acceleration is REALLY cool, in my machine, using very
> optimized 2D rutines, the performance increases using the Virge HW accel
> like this:
> - lines: 20%
> - boxes: 74%
> - hlines: 64%
> - vlines: 13%
It is not very much But maybe your main CPU is very
fas
Brent Fulgham wrote:
> A few Hurd folks are making noises about porting KGI/GGI onto the Hurd.
> At one time a few of you were somewhat interested in this, but didn't
> make much progress.
>
> Can a kind, knowledgable soul join our "debian-hurd" mailing list and
> provide some technical support?
Andreas Beck wrote:
> Marcus will be extremely grateful, if you can take out the SYNC mode stuff
> from XGGI. I know he doesn't like SYNC mode much, much less than I actually,
> and if he didn't manage to get XGGI running ASYNC, that tells a story.
>
> But anyway: GO FOR IT ! Someone should fina
James Simmons wrote:
> > Can be any. This behaviour is usually a bug.
> > I'll explain it a little further below:
>
> Well that kills that idea. I was hoping that often the poblem was that the
> accel engine was updating area that another process was access via the
> framebuffer. If this was the
Marcus Sundberg wrote:
> Yes please! We really need a GUI toolkit running on LibGGI.
BTW, I have integrated within the OpenAmulet toolkit [1]
some support for GGI. The library relies on libgwt,
which is not-so-good - but all in all it can successfully
display the interface of some of the test pro
Tobias Barth wrote:
> Is there anything speaking against hardware mouse cursors?
No. But currently, within XGGI, it's easier to use
software cursors (due to the lack of some management
functions for cursors in the LibGGI middleware).
Rodolphe
Andreas Beck wrote:
> It just polls the accelIdle bit and waits for it to come up while the ioctl
> is still running.
Alternatively, some cards can also send an interrupt when the accel
engine has finished, no ? (But you need to protect the critical
section whatsoever.)
> On SMP machines, you wi
[EMAIL PROTECTED] wrote:
> The problem is, that on cards that lock up, we cannot rely on applications
> acquiring this lock. An mmaping/unmapping the framebuffer is the only way to
> ensure that an application can/cannot access the framebuffer.
Wait a minute. For me a 'kernel lock' is not acquire
[EMAIL PROTECTED] wrote:
> It is handled by the MMU hardware. And that is the problem. Well - actually
> it is the only way to have decent speed :-).
OK. So, you need to unmap (to trigger page faults at least). I agree with
you.
I thought finer kernel control was possible.
> > However, it seems
Hello,
just in case you have some free time, you may be
interested in this web page (wrt. driver writing).
http://www.irisa.fr/compose/gal/
Rodolphe
Jos Hulzink wrote:
> The original loop GCC creates was about 9 instructions long, increasing
> addresses made a mess of the code, so I had to decrease them. The only way
> that produced neat code was treating the Z-buffer like an array of kgiu32
> values.
Do you mean that the loop was unrolled or
DrEvil wrote:
> Everytime I run the configure script for GGI, it doesn't find glide.h, or
> glide/glide.h
>
> I have the glidesdk installed, the include files are in /usr/include/glide/
>
> Where do I put the fracking glide includes, so configure will find them?
the env. or shell variable CFLAG
Steffen Seeger wrote:
> a new snapshot is in place at http://www.tu-chemnitz.de/sse/ggi.
The right adress is http://www.tu-chemnitz.de/~sse/ggi/
Keep the good work btw... Bye,
Rodolphe
"Jon M. Taylor" wrote:
> * Window manager hooks are unimplemented. This should probably be
> implemented using LibGWT/LibWMH...?
AFAIK libwmh is really for X11 Window managers hooks ? Is it
what it needed ?
Concerning libgwt, it is still a 'conventional' library (not
really an extension in the
Marcus Sundberg wrote:
> If you need to write everything from scratch there may be problems,
> but the right way to do windowing/widgets on top of LibGGI is really
> to finish LibGWT and port libgdk (the wrapper that GTK+ uses around X)
> to it. Then you would be able to use any GTK+ application d
Hello,
In the README.install of kgi-991208.tgz, Steffen Seeger wrote:
...
NOTE: The board needs to be the second VGA board installed (not the boot-VGA).
...
Steffen, is this note specific to the Permedia driver, or is it a general
issue ? (One of these days, I'd like to have a look at porting
Steffen Seeger wrote:
> It's a general issue. The kgim-0.9 code as well as the kgi_register_display()
> code do not yet agree how to do consoles after the display driver got
> loaded. Therefore, in order to have a working display after the driver
> got loaded, you need to have a normal VGA the dri
Firstname Lastname wrote:
> Hello. After haveing put some effort into trying to get GGI working on my
> system, I am now quite confused.
Some of your 'renaming' assumptions are wrong. So, for example, fbcon
and KGIcon are _separate_ things.
>
> I am running debian, so i installed the libggi2 pa
Thank you for all this work. Steffen, I guess you will
tell us when you have a KGI distrib. with these things?
Rodolphe
"Jon M. Taylor" wrote:
> I am flying out to the LinuxWorld Expo at New York City at the
> beginning of February with my boss. We will be speaking at Eric Raymond's
> '
Julien Tayon wrote:
> XGGI will be running on a video
> wall, the name of the product is elixir and the vendor (our client) is
> synelec.
For those interested, http://www.synelec.fr/ should provide
some info.
> I would like personnaly to thank everybody for having been so nice.
Tu rigoles... (H
Andreas Beck wrote:
> A few thoughts about multithreading LibGGi3d:
> > - better scaling on SMP-machines
>
> And worse on non-SMP, or if the number of processes exceeds the number of
> CPUs. Note, that you will often have to switch between modules very rapidly
> to avoid having large queues that
teunis wrote:
> And if anyone has any ideas on how to profile a multithreaded app, let me
> know :)
Well, take care to store your profiling information _inside_ memory,
and output them to disk or terminal all in a bunch (preferably at the
final end of the program). If you are on a uniprocessor, r
teunis wrote:
> mutex locking time is... *heh* around 26000 microseconds... Longer than
> poll() Go figure.
So much ? Well, it must be implemented via a system call then...
Well, with threads managed by the kernel it is not so astonishing,
but you can surely do much better if you only want
Andreas Beck wrote:
> > quite extensively but as I heared, the visual structure itself
> > is too complex to be used for that.
>
> Depends. For backing store of whole windows and such, I see no problem.
> But for a few dozen sprites it's a bit heavy. However when you stuff the
> sprites onto a si
Well, first of all, let me say that the ideas of Andreas
concernin libwmh, and a X-style window manager seems perfectly
acceptable to me.
Marcus Sundberg wrote:
> To me it sounds like what you really want is a window system running
> directly on top of LibGGI, which really would be nice to have.
If I guess correctly, here is a beautiful example of
the 'elixir' system (i.e. of XGGI over devfb + custom
hardware, especially display hardware).
http://perso.club-internet.fr/ftoussin/photos/03.jpg
Rodolphe
PS: The reporter home page is:
http://perso.club-internet.fr/ftoussin/photos/p1.html
(
On Sun, 5 Mar 2000, Andreas Beck wrote:
> > with me... :-)) I also have the "NeoMagic" concern.
> > If someone get access to the docs concerning this chipset, I'd be
> > interested to know...
>
> Hmm - how about the XFree sources or reverse engineering the Windoze
> driver ?
Well, at least in
Just a note, I recently fell around GNU 'libxmi' which seems to be "the
drawing functions of X11 stand-alone" (available from your nearest
www.gnu.org site). It's pretty small and covers much of X11 drawing
aspects (but only the algorithms, nothing more)...
Should potential connections (to do, c
On Sun, 5 Mar 2000, Andreas Beck wrote:
(as an answer to this question from myself)
> > Should libggi2d support arbitrary clipping - or would it be acceptable to
> > have a 'small' version with only rectangular clipping ? (But with decent
> > drawing functions.)
>
> I don't think LibGGI2D shoul
On 7 Mar 2000, Thomas Mittelstaedt wrote:
> GGI - as far as I know - has only a notion of a rectangular clipping
> rectangle being valid for all subsequent primitive drawing calls.
> Well, what, if I have a clipping region, like X does, which I can
> subdivide into an enumeration/array of rectan
On Fri, 3 Mar 2000 [EMAIL PROTECTED] wrote:
> Thomas wrote previously:
> > is it possible to use kgicon / fbdev together with the
> > Neomagic card on a Notebook?
>
> AFAIK there is no KGI driver for the neomagic, but it is known to work with
> the generic vesafb driver in the kernel.
>
> One
On Thu, 2 Mar 2000, Eric , Yu-En Lue wrote:
> > Should potential connections (to do, considered, already done) between
> > libxmi and libggi2d be explored further ?
>
> it's algorithms , data structures are mostly done and rather
> imcompatible with ggi , I don't know how clipping wo
On 8 Mar 2000, Thomas Mittelstaedt wrote:
> I have an instant need to be able to draw Arcs, RoundRects and
> Polygons etc. So, if somebody of the GGI project can give me
> guidance, I can jump right into integrating libxmi, since libggi2d
> just does not work. I already installed libxmi. There
On Wed, 8 Mar 2000 [EMAIL PROTECTED] wrote:
> > (set-of-non-overlapping-rectangles) in LibGWT.
> > I have the feeling of initiating too much workload wrt to graphic context
> > switch. (Basically, the way it is done is a loop over all the rectangles
> > composing the region while calling set-GC
On Sat, 11 Mar 2000, Jon M. Taylor wrote:
> Sure. I'll try to collect all the ideas from the mailing list
> archives and come up with a proposal over the weekend. Is there still any
> interest in the LibXMI idea, or should I assume that we are trying to
> design the ideal 2D library from
On Sat, 11 Mar 2000, Jon M. Taylor wrote:
> Any clipping shapes at all can be handled with a 1bpp stencil
> mask.
I also wonder if this method wouldn't be the most convenient one to
provide (arbitrary) clipping in libggi2d. It may be.
Furthermore, as this clipping may be done in the last
Hello,
well, I've just committed my most recent updates to LibGWT to the CVS
repository (degas).
Don't expect too much revolution in it but it may be cleaner.
I've just updated my own local GGI tree to do the synchronization work for
LibGWT against the other libraries now. (The latest version is
On Wed, 15 Mar 2000, Jon M. Taylor wrote:
> http://tanuki.dhs.org/libxmi.tar.gz
I have a compilation problem with the version above:
$ nice make -s
Making all in include
Making all in ggi
Making all in xmi
Making all in display
Making all in xmi
/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFI
On Thu, 16 Mar 2000, Jon M. Taylor wrote:
> > I'll try to understand the problem. But I have to figure out the overall
> > thing first (and you may find the problem as soon as you wake up...:-))
>
> Wait for the new tarball.
I'm waiting... :-)) See you tomorrow...
Rodolphe
Hello,
well, I've just committed some modifications to LibGWT and uploaded
a development snapshot of OpenAmulet containing my latest updates to
the GGI 'platform'.
This is still a very EXPERIMENTAL piece of software, but I find it fancy
and I'd like to share it with you. More precisely, I'd be in
On Mon, 20 Mar 2000, Andrew Apted wrote:
> Jon M. Taylor writes:
> > Bugreports and patches are appreciated.
>
> Okidoke: demos/demo gives me a short line of three dashes on the
> screen, then it segfaults with the missing symbol as you said.
> xmitest segfaults immediately with a missing symbo
Hmmm... This is a followup to my own last mail... (sorry)
In fact, I observe the same behavior as Andrew Apted - but after libxmi
has been INSTALLED (w/ make install).
Without the 'install' there is no segfault, but no pixels drawn.
After the install, there are pixels, but also the segfault.
R.
I've just noticed that I have strange display problems with the OpenAmulet
test programs when running in 8bpp. (CrossBlit behaves strangely it
seems.)
I usually run X in 16bpp so I did not notice earlier. I'm currently trying
32bpp... :-) ... it runs well also.
Well, it seems these problems occu
Hello,
I successfully run libxmi demo program (with exactly the behavior you
mentionned). I intend to use it RSN inside the OpenAmulet library
framework? However, for this, I'll need to write XMI wrapper functions
inside LibGWT first. But 2D drawing functions were the LAST missing part.
Now OpenA
On Mon, 17 Apr 2000, Andreas Beck wrote:
> > Which look&feel has OpenAmulet? Is the look&feel changeable?
>
> Yes, that's one of the fun points about Amulet. You could change the
> look&feel to Mac, Win and Motif. I don't know, if they enhanced that
> concept to get it kind of themeable.
No
On Tue, 18 Apr 2000, Stefan Seefeld wrote:
> Well, from a practical point of view, how would I manage multiple input
> queues ? Given a list of visuals (as you seem to suggest) acting as window,
> I'd be forced into one thread per visual if I want to listen for events.
I had such a problem with
Is it possible to have several miPaintedSet per ggi_visual_t ?
If yes, why (ie: what can be done with this feature) ?
Why are there 2 declarations of miDrawArcs in xmi.h ? (POSSIBLE BUG: one
of them should be reentrant and tagged _r no?)
Are any special interactions to take care of between
miCo
On Mon, 24 Apr 2000, Jon M. Taylor wrote:
> On Sat, 22 Apr 2000, Rodolphe Ortalo wrote:
> >
> > Is it possible to have several miPaintedSet per ggi_visual_t ?
>
> Sure, in fact miPaintedSets are not tied to any one ggi_visual at
> present, although this may c
On Thu, 27 Apr 2000, Andreas Beck wrote:
> > BTW: I have a polygon in a window now :-)
>
> WHAT ? Freedom for the polygons ! No more mutilation by clipping windows !
> (SCNR ... :-).
Don't worry, I am not such a cruel minion: just gwtRaise() the window to
the top level... :-))
(Still a lot o
Hello,
well, I have a few questions I'd like to raise over the way I can use
the LibXMI framework within LibGWT.
First, I wonder if I should allow several paintedSet and several miGC per
window (option 1), or hide these XMI abstractions inside a GWT window
(option 2).
With option 1, the drawing
Thanks for your answers Jon.
On Sun, 30 Apr 2000, Jon M. Taylor wrote:
> If you can, the best way to overload existing library
> functionality in an extension is to 1) establish a one-way dependency
> between the libraries (a LibXMI target for LibGWT), and B) overload the
> existing XMI API
1 - 100 of 125 matches
Mail list logo
