Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except perhaps to the
On Mon, 27 Jan 2003 22:37:06 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
C code can be edited with any text editor, too. But the percentage
of DRI users that can usefully DO that, is a very small number,
comparative to the overall number of users.
Hence the GUI ... I think I have
On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
So what are the technical advantages of XML in this case?
Quick List --
*) Text Based - easy to edit.
Text based does NOT imply easy to edit. look at USBsnopys' output. its
completely illegible.
*) Well
On Tue, 28 Jan 2003 01:25:48 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
what alternative do you propose that would be faster? Are we talking
seconds, minutes, hours ... what?
On some systems, every nanosecond counts.
---
This SF.NET
On Tue, 28 Jan 2003 02:05:34 +0200
Arkadi Shishlov [EMAIL PROTECTED] wrote:
It is also possible to rebuild XML parser in some binary
incompatible way..
or find someone compiled their own broken one.
---
This SF.NET email is sponsored by:
On Mon, Jan 27, 2003 at 10:41:20PM -0600, D. Hageman wrote:
Those are some excellent examples of abuse. It doesn't have to be like
that.
[..]
If we went with libxml2 it has no exterior dependencies that I am aware.
Probably I was harsh when I said no to XML. Using libxml is good from
On Tue, Jan 28, 2003 at 10:37:03AM +, Ian Molton wrote:
On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
So what are the technical advantages of XML in this case?
Quick List --
*) Text Based - easy to edit.
Text based does NOT imply easy to
Philip Brown wrote:
On Mon, Jan 27, 2003 at 10:37:06PM -0600, D. Hageman wrote:
On Mon, 27 Jan 2003, Philip Brown wrote:
Preferably in an area that XML was designed for: in exchanging
data between programs and OTHER programs, not between humans and programs.
Simplify: GUI configuration
Ian Molton wrote:
On Tue, 28 Jan 2003 02:55:22 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
*) Every major programming language has some library to handle XML
(say if you hacked togther a library that does the XF86Config file
format ... this wouldn't be the case).
Irrelevant in this
Title: GAZETE KEYFÝ
Gazete Keyfi...Her sabah güne baþlarken içinizi ýsýtacak bir site burasý...Sýcacýk çayýnýzý yudumlarken ya da yemekten sonra kahvenizi içerken alacaðýnýz keyfi ikiye katlayacak, Türkiye ve Dünyada neler olup bittiðini izleyebileceðiniz, günlük bulmacanýzý çözebileceðiniz,
Damien Miller wrote:
Philip Brown wrote:
On Mon, Jan 27, 2003 at 11:18:43PM +0100, Felix Kühling wrote:
If anyone has serious objections to XML, please let us know (mail to
dri-devel will suffice ;-).
I object. Using xml inevitably leads to files that are completely
human-unreadable, except
Ian Molton wrote:
On Tue, 28 Jan 2003 01:25:48 -0600 (CST)
D. Hageman [EMAIL PROTECTED] wrote:
what alternative do you propose that would be faster? Are we talking
seconds, minutes, hours ... what?
On some systems, every nanosecond counts.
There are four times when the configuration file
Keith Whitwell wrote:
Ian Romanick wrote:
Did you ever monkey around with their 16-sample texture filter (the
anisotropic mode)? I played with that a bit, but every time I
selected that mode it would crash the graphics chip. :(
No, never tried it. Do you have to somehow dedicate both
When we did the powervr.ini file structure we ported code from our Win32
drivers which used the same file structure. But Win32 offers an API to
read/write those kind of files, while for the Linux driver we had to rewrite
it from scratch. (not fun always :). But it satisfied our needs good enough.
I'm not a developer and I know nothing about XML and so have no real
opinion as to what the file format should be. I am however woried about
comments like the ones quoted below. The notion that users dont edit
config files by hand may be all fine and good in the microsoft world but
last time I
[...] The notion that users dont edit
config files by hand may be all fine and good in the microsoft world but
last time I checked I was using linux. You can't make the same
assumptions about what users want to do as you can in the microsoft
world.
I'd like to add _strong_ support to
Vlad Stamate wrote:
When we did the powervr.ini file structure we ported code from our Win32
drivers which used the same file structure. But Win32 offers an API to
read/write those kind of files, while for the Linux driver we had to rewrite
it from scratch. (not fun always :). But it satisfied
Hi,
I recently discovered some problem with normal vectors in the gflux hack
on my Duron, Radeon 7500 with and without TCL, even with
RADEON_NO_RAST=1. LIBGL_ALWAYS_INDIRECT works correctly, though.
A workaround is MESA_NO_3DNOW=1. Another way is to normalize the normals
in gflux and change
Well, you are right. When a new app starts it does cache the file. So if
something else modifies the file (ini file) the OpenGL app will only know if
it needs to write and therefore synch.
BTW there is tool that modifies our files: KLT (Kyro Linux Tools).
Anyway I am glad to be of help.
Vlad
Hello all :-)
I have an unusual problem I'm hoping someone can help me with.
I'm trying to compile the DRI from within a chrooted linux
environment on FreeBSD. I've encountered a few errors that I've been able
to work through (I needed to install perl, create /tmp, etc.), but
D. Hageman wrote:
Hence the GUI ...
GUI...
Seriously, if you a technical reason why ... I would love to hear it.
Technical reason? XML is Bad By Nature, what reason do you expect? :)
Never heard such a lame thing as using a GUI (who needs that) to edit
XML (who needs that) ...
(pls don't
Adam K Kirchhoff wrote:
I'm trying to compile the DRI from within a chrooted linux
environment on FreeBSD. I've encountered a few errors that I've been able
to work through (I needed to install perl, create /tmp, etc.), but this
one has me stumped.
When it starts to compile the ATI drivers,
On Tue, 28 Jan 2003, Dieter Nützel wrote:
Am Dienstag, 28. Januar 2003 08:22 schrieb D. Hageman:
On Mon, 27 Jan 2003, Philip Brown wrote:
I am trying to point out that none of
[-]
On the other hand,
DRI is meant to integrate with XFree86. XFree86 has a standard
[ Ian wrote ]
There have been rumblings on [EMAIL PROTECTED] about problems with
Radeon in 4.2.99.4, but I didn't think that those problems had
propogated into DRI CVS yet. That's a shame. :(
I think it's the other way round: The DRI stuff that got merged into XFree86
4.2.99.x 'releases'
Well, that solved that particular problem :-)
I don't think that's fixed all my problems, though. Let me grab a clean
copy of the CVS, patch that file, do a make World again, and post any more
problems I end up having.
Adam
On Tue, 28 Jan 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Hallo
We've been discussing general issues regarding the new DRI configuration
system recently on IRC. The most user-visible issue is the configuration
file format (until there is a GUI tool ;-).
In any case we need a more structured (nested) format than win.ini since
we want to be able to
Ian,
Well, the build isn't done yet, but it's much further along now,
having built the GL library and the Direct Rendering Library, as well as
the 2D drivers.
FYI, the problem with the r128 driver also exists in the texmem
branch, which errored at the same point. I don't know,
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm
D. Hageman wrote:
On Tue, 28 Jan 2003, Ian Romanick wrote:
How do we want to handle the case where a user changes video cards?
Some of the parameters are likely to be generic, but a lot will be very
device specific. The issue here is that the set of available parameters
will change. A
device id=0
application name=...
...
/application
application name=...
...
/application
/device
I'm coming to conclusion more the more I think about it. I really can't
come up with a good, real-world case to argue for
Hi
Just one little XFree-related pro-XML story. Not from DRI, from XKB
life. You know, XKB configuration is generally held in
/usr/X11R6/lib/xkb directory and several subdirectories. All this would
be fine if the format of the files in these directories would be
something good, structured,
On Tue, Jan 28, 2003 at 03:51:26PM -0500, Jamie Guinan wrote:
If the XML can be kept relativly simple to read and edit then fine but
the end user should never have to use a config tool if they don't want
to. So please keep it as simple as possle. In my opinion the
readability of the
On Tue, 2003-01-28 at 12:00, Sven Luther wrote:
Just my experience for when file-roller (part of gnome) upgrades its
configuration, it takes minutes on a Atlhon 1700+, but i admit, the
configuration file-roller manages are, if not big, at least there are
many of them.
Thats something else.
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize prefetching. The next normal was read into MM0 and MM1 at the
end of the G3TN_norm
Philip Brown wrote:
If you think about it, what *really* matters is the bytes inside DRI.
The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes it *trivial* to write tools
If you think about it, what *really* matters is the bytes inside DRI.
The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes it *trivial* to write tools for people
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
It seems I like answering my own mails ;-)
I fixed this problem but it is probably not optimal. A simple patch is
attached. It seems that this error was introduced by an atempt to
optimize
On Tue, Jan 28, 2003 at 09:56:09PM +, Sergey V. Oudaltsov wrote:
Hi
Just one little XFree-related pro-XML story. Not from DRI, from XKB
life. You know, XKB configuration is generally held in
/usr/X11R6/lib/xkb directory and several subdirectories. All this would
be fine if the format of
On Tue, 28 Jan 2003, Philip Brown wrote:
If you think about it, what *really* matters is the bytes inside DRI.
The XF86Config syntax is just sugar to make it easy to get the right
values in there for people handy a text editor. An XML syntax is just
different kind of sugar which makes
Felix Kühling wrote:
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Good catch. It looks like this went into the Mesa tree back in October
On Tue, 28 Jan 2003, Ian Romanick wrote:
The thing that makes XML worse is that it gives people an extra degree
of freedom. This amounts to giving people more rope with which to shoot
themselves in the foot.
LOL.
/me holds rope
/me looks at foot
/me scratches head
--
Leif Delgass
Good story. But right there, you point out the main difference between your
example, and the XFree86 config format.
Keep in mind - it is not XF68Config, it is just configuration
repository. The tree of available modeuls/layouts/variants/options. Not
actually chosen one (which is still in
On Tue, 28 Jan 2003, Ian Romanick wrote:
As far as caching goes, I guess I don't understand. Does that mean that
if someone changes settings while an OpenGL application is running, the
changes will take effect in the running app? Will it only take effect
if the app creates a new rendering
On Tue, 28 Jan 2003, Felix Kühling wrote:
prefetching looks odd to me. In the first transform loop in
_mesa_3dnow_transform_normalize_normals memory is prefetched which is
never read but only written. This is obviously useless. Then in the
No -- at least not *obviously* useless. Whether it
Am Mittwoch, 29. Januar 2003 00:05 schrieb Ian Romanick:
Felix Kühling wrote:
On Tue, 28 Jan 2003 13:10:41 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
Felix Kühling wrote:
The patch moves the load operations back to the front of the loop as in
the G3TN_norm_w_lengths case.
Good catch.
On Wed, 29 Jan 2003, Arkadi Shishlov wrote:
Hi.
I'm working on QuakeForge engine, and some things related to transparency
(player damage blood) and 'dynamic lighting' (grenade explosion) are very
slow. Quake3 runs faster in mean time.
Quake3 has some hacks built in to work around the
I am attempting to recompile DRI on my newly
configured Mandrake 9.0 system..
but it cuts out with an error on line 14282 or so
of my log file..
with an error in a gcc line..
it's the only place it tries to use the Xpm library
"-lXpm"
and for some reason, it says it can't find
it.
Any
On Tue, 28 Jan 2003, Ian Romanick wrote:
How do we want to handle the case where a user changes video cards?
Some of the parameters are likely to be generic, but a lot will be very
device specific. The issue here is that the set of available parameters
will change. A releated issue is
I think a better approach would be to add a level of indirection between
the app and the card - reason to follow this example:
device card=radeon
setting name=games
tcl=enabled/
dramclock=100MHZ/
...
/setting
setting name=detailwork
tcl=enabled/
On Tue, 28 Jan 2003, Ian Romanick wrote:
D. Hageman wrote:
On Tue, 28 Jan 2003, Ian Romanick wrote:
How do we want to handle the case where a user changes video cards?
Some of the parameters are likely to be generic, but a lot will be very
device specific. The issue here is that the
50 matches
Mail list logo
