You can subscribe to this list here.
2001 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(34) |
Aug
(59) |
Sep
(16) |
Oct
(11) |
Nov
(83) |
Dec
(52) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(40) |
Feb
(82) |
Mar
(190) |
Apr
(72) |
May
(95) |
Jun
(128) |
Jul
(195) |
Aug
(267) |
Sep
(202) |
Oct
(88) |
Nov
(60) |
Dec
(34) |
2003 |
Jan
(81) |
Feb
(73) |
Mar
(74) |
Apr
(53) |
May
(15) |
Jun
(61) |
Jul
(32) |
Aug
(73) |
Sep
(121) |
Oct
(43) |
Nov
(27) |
Dec
(47) |
2004 |
Jan
(46) |
Feb
(90) |
Mar
(97) |
Apr
(87) |
May
(71) |
Jun
(103) |
Jul
(61) |
Aug
(15) |
Sep
(49) |
Oct
(32) |
Nov
(26) |
Dec
(4) |
2005 |
Jan
(33) |
Feb
(15) |
Mar
(27) |
Apr
(21) |
May
(29) |
Jun
(20) |
Jul
(16) |
Aug
(10) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
(2) |
Feb
(9) |
Mar
(2) |
Apr
(7) |
May
(20) |
Jun
|
Jul
|
Aug
(13) |
Sep
(20) |
Oct
(11) |
Nov
(10) |
Dec
(7) |
2007 |
Jan
(12) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(2) |
2008 |
Jan
(10) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(1) |
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2011 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: David L. P. <pa...@gm...> - 2008-04-30 15:04:58
|
Most of the following discussion follows other postings within the chromium-users mailing list as I was hashing through this problem. I've included it below for clarity and completeness as I am now trying to modify the CR code to better handle this situation rather than the kludge I posted in the users mailing list. I am looking into the problem that I have had on my Windows system with CR. The difficulty centers around manifest files (i.e. app.exe.manifest) associated with Microsoft Visual Studio 2005 (MSVS 2005) and up. It seems that the MSVS 2005 compiler creates ".manifest" files that are somehow important to runtime linking. In CR with Windows, the app faker first copies the exe for an app of interest to a temp dir and then copies crfaker.dll into that same dir with the name opengl32.dll. My understanding here is that this approach allows crfaker.dll to mascarade as the OpenGL library since the linker will first look locally within the temp dir for important dll's to link since the app.exe resides in that temp dir. The problem is that the app.exe.manifest file is not copied by CR (app faker) into temp dir, as well. Without the manifest file some apps generate runtime linking errors. The one I have run into is not finding MSVCR80D.dll. There seems to be three ways to resolve this issue (can anyone think of any others?). Does anyone have a recommendation or additional comments as to what approach would be best? (1) The kludge (in my opinion not the best approach) is to embed the manifest file into the exe file as noted in the MSDN note ( http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx). I have found this works, but it goes against the spirit of CR since one must modify the OpenGL app of interest. (2) Modify app faker to copy the app.exe.manifest (if it exists) to the temp dir at the same time that it copies the app.exe file. I have made this mofication and it seems to work as well. However, another issue that might arise is .local (dot local) files. I don't know much about these files but an app can have an app.exe.local, which seems to force Windows to check a local directory first for a dll. This behavior would seem to be affected if app faker is not copying the app.exe.local file and any local dll's along with app.exe. (3) Another approach is to copy crfaker.dll with the new name of opengl32.dll into the current directory of the app.exe file and then to spawn the app from it's current directory. For this approach to work, it would seem necessary to have an app.exe.local file to insure that Windows first looks locally for opengl32.dll. I haven't tried this approach yet as I'm not totally familiar with dot local files or Windows dynamic linking. With that said, this approach seems the most promising to me. My question to the CR developers is what approach seems to be the best from your experience? What guidance would developers have? I am currently looking to modify app_faker.c and to follow (3) above as it seems to be the best approach to handle all scenarios. A post to the chromium-users list noted a simliar solution, and the key to (3) seems to be the .local (dot local) file. I look forward to any help and guidance. Best regards, --Dave -- David L. Page, PhD dav...@ie... 865.607.8192 |
From: Sterling A. <st...@mi...> - 2008-04-17 18:34:59
|
Hello all, I am an MIT graduate student working with MIT Ventureships and a new startup company that is marketing patented technology for auto-edge blending and warping of images from multiple projectors into one cohesive image. Brian Paul suggested that I post to this list to ask if any of you or your clients might find this technology particularly useful. Basically, this company's software provides a quick, versatile, and automated blending and warping of images from multiple projectors into one cohesive image. This technology is being used to create large, bright, high-resolution projections by using multiple, low-cost projectors. We think this patented technology has the potential to disrupt standard paradigms for producing immersive display environments at low costs. If any of you get a chance and can help me answer a couple of questions (listed below), I'd really appreciate it. * Are the folks you've worked with interested in having larger displays or higher resolution displays? Why? * How do your customers interact with the screens? * Do you or your customers already work with discrete displays? * Is there any advantage to making them seemless? * Does screen geometry play much of a role with users of Mesa and Chromium in the scientific visualization community? Thanks, Sterling Anderson st...@mi... 617-258-8428 http://web.mit.edu/mobility/ |
From: Gelson R. <gel...@ho...> - 2008-03-12 16:42:49
|
Hi, I'm trying to use Tracker SPU on Chromium. I have a Flock of Birds tracker with one sensor and my intention is to use all in Windows XP on Cygwin environment. I did built all Chromium framework (from CVS repository) and it run very well, but when FOBTrackerCSharp app send data to TrackerSPU a warning message tell me that "CR Warning(myServer:0): Tracker SPU: Invalid datagram for tracker SPU" and nothing change in visualization when FOB sensor is moved. I put custom debug message in trackerspu_udp.c and I can see that connection between sockets is working, but i believe that data arrive corrupt. Have somebody idea what is going on? My test environment: 2 pc (host1, host2) running Windows XPhost1: Running CSharp FOB tracker working very well (here I set IP Address = host2_IP)host2: (Cygwin) Running Python tracker.conf + 6 crserver + 1 crappfacker (here I changed only in tracker.conf listen_ip = host2_IP (almost default configuration) Thanks a lot for help,Gelson P.S.: Please sorry very much for my bad english! _________________________________________________________________ Veja mapas e encontre as melhores rotas para fugir do trânsito com o Live Search Maps! http://www.livemaps.com.br/index.aspx?tr=true |
From: Alan H. <al...@tu...> - 2008-03-10 23:51:23
|
On Mon, 2008-03-10 at 17:24 -0600, Brian Paul wrote: > IOhannes m zmoelnig wrote: > > as shown on the chromium-users list, i had some "problems" with chromium > > not exposing glx-functions properly (well, it's not exposing them at > > all) via the crGetProcAddress() which gives me weird errors when using > > glew. > > > > i decided to just add these functions to chromium myself. > > since there is no "patches-tracker" at the sourceforge project page, i > > guess i post my changes to this list. > > > > according to alan, i put all the changes directly into getprocaddress.py > > (i also tried to put it into glapi_parser/APIspec_glx.txt (following the > > APIspec.txt scheme) but since i found now way to reset > > apiutil.GetAllFunctions() i went the easy route...) > > > > i don't know whether this is a good idea to do at all, but at least my > > error goes away :-) > > Looks good. > > I'd commit it to CVS but SF CVS doesn't seem to be working today. Can > someone else try? Yep, done. Alan. |
From: Brian P. <bri...@tu...> - 2008-03-10 23:25:03
|
IOhannes m zmoelnig wrote: > as shown on the chromium-users list, i had some "problems" with chromium > not exposing glx-functions properly (well, it's not exposing them at > all) via the crGetProcAddress() which gives me weird errors when using > glew. > > i decided to just add these functions to chromium myself. > since there is no "patches-tracker" at the sourceforge project page, i > guess i post my changes to this list. > > according to alan, i put all the changes directly into getprocaddress.py > (i also tried to put it into glapi_parser/APIspec_glx.txt (following the > APIspec.txt scheme) but since i found now way to reset > apiutil.GetAllFunctions() i went the easy route...) > > i don't know whether this is a good idea to do at all, but at least my > error goes away :-) Looks good. I'd commit it to CVS but SF CVS doesn't seem to be working today. Can someone else try? -Brian |
From: IOhannes m z. <zmo...@ie...> - 2008-03-10 15:26:19
|
as shown on the chromium-users list, i had some "problems" with chromium not exposing glx-functions properly (well, it's not exposing them at all) via the crGetProcAddress() which gives me weird errors when using glew. i decided to just add these functions to chromium myself. since there is no "patches-tracker" at the sourceforge project page, i guess i post my changes to this list. according to alan, i put all the changes directly into getprocaddress.py (i also tried to put it into glapi_parser/APIspec_glx.txt (following the APIspec.txt scheme) but since i found now way to reset apiutil.GetAllFunctions() i went the easy route...) i don't know whether this is a good idea to do at all, but at least my error goes away :-) gfmasd.r IOhannes |
From: Zacarias <mrz...@gm...> - 2008-02-28 20:04:34
|
Hi o/ I'm triyng to install chromium on windows, with cygwin... But i'm having so many problems with the compilation. Someon have installed chromium on windows before and can help me to do it? Or provide to me the resultant files of compilations? Thanks a lot! -- Márcio Rocha Zacarias |
From: Ricardo J. <rj...@im...> - 2008-02-20 17:21:16
|
Hi, I'm trying to compile chromium on OSX 10.5 (PPC) and even though the F.A.Q says that there are some issues with OSX I decided to download the CVS version and give it a go. - First and foremost, there seems to be something weird on the .mk files because chromium only start to compile on /cr. (~/cr does not even works). My guess is because of the OpenGL.Framekowk links Darwin.mk creates. This is not a big issue, he does start to compile on /cr. - Next the CVS version is configured with warn_error and, on Darwin 10.5, AGL seems to be deprecated: == warning: 'AGLDevice' is deprecated ==. For now I just removed the -warn_error flag. - However, when he starts the action == Building libcrfaker.dylib for Darwin (DEBUG) (THREADSAFE) == the following error occurs: cgl.c:161: error: conflicting types for 'CGLChoosePixelFormat' /System/Library/Frameworks/OpenGL.framework/Headers/OpenGL.h:28: error: previous declaration of 'CGLChoosePixelFormat' was here cgl.c:287: error: conflicting types for 'CGLDescribePixelFormat' The same error is given when compiling the following: CGLCopyContext, CGLQueryRendererInfo, ... , CGLGetVersion, etc. Has anyone successfully compiled chromium on OSX. If so, what am I doing wrong? Cheers, Ricardo Jota |
From: Robert E. <pa...@tu...> - 2008-01-16 19:21:04
|
> throughout the code I'm finding files with the name "*_special" that > list some subset of the OpenGL API. I'm having a hard time deciphering > for each of these files what criteria causes a function to end up > here. They are obviously manually constructed. The "*_special" files are typically used with Python code generation scripts, and indicate a function that for some reason or another cannot be handled with automatically generated code, and instead must be handled with "special" code. Sometimes this is because the code generation script isn't complete (and complex) enough to handle all possible generic function specifications (from APIspec.txt); sometimes it doesn't make sense to spend hours carefully crafting the code generator to handle just a few unusual cases that you could otherwise code in a few minutes. Sometimes it's because APIspec.txt doesn't include just the right classification code for a group of functions that could be used to automatically generate code for them; the only alternative to defining a new classification and going through every function in APIspec.txt to figure out which functions need the classification (a very pervasive action) is to create a "*_special" file. Sometimes it's because the whole point of a generated SPU is to provide special implementations of just certain functions, while providing common handling for all others (e.g. the "expando" SPU). Sometimes it's because some functions or classes of functions really need special handling that can't be automated for a given use. In general, unfortunately, you have to have a pretty intimate understanding of what sort of code generation is going on and why in order to figure out what belongs in a "*_special" file. That's hard enough if you're modifying an SPU, but quite a bit more difficult if you're adding functions to APIspec.txt. As a first pass, I'd recommend the same thing Brian did: find functions that behave like the new functions do, and make their entries in APIspec.txt and "*/*_special" files similar. As you test, you'll inevitably find places that you missed or incorrect categorizations; fix the ones that you find, and the next guy will fix the ones that he finds, etc... Bob Ellison Tungsten Graphics, Inc. |
From: Chris B. <cb...@ta...> - 2008-01-16 16:07:17
|
Hi All, throughout the code I'm finding files with the name "*_special" that list some subset of the OpenGL API. I'm having a hard time deciphering for each of these files what criteria causes a function to end up here. They are obviously manually constructed. This project is starting to look bigger than I had originally thought, mostly due to my lack of familiarity with Chromium's source code. Is there any interest by anyone on this list to collaborate? For the record, the project is to get Chromium to support the four ARB extensions that are used to support GLSL (GL_ARB_shader_objects, GL_ARB_vertex_shader, GL_ARB_fragment_shader, GL_ARB_shading_language_100). Chris~ |
From: Robert E. <pa...@tu...> - 2008-01-15 18:53:02
|
> Also, I'm not clear on what all of the "props" and "chromium" props > values in the APIspec.txt file really mean. In particular, i dont' > understand what "nolist" means and whether a given function should use > it, and I'm not sure how to determine whether a given function should > be tagged "pack" or "extpack". Off the top of my head... The glNewList man page lists the functions that are considered to be "nolist": > Certain commands are not compiled into the display list but are exe- > cuted immediately, regardless of the display-list mode. These commands > are glAreTexturesResident, glColorPointer, glDeleteLists, > glDeleteTextures, glDisableClientState, glEdgeFlagPointer, > glEnableClientState, glFeedbackBuffer, glFinish, glFlush, glGenLists, > glGenTextures, glIndexPointer, glInterleavedArrays, glIsEnabled, > glIsList, glIsTexture, glNormalPointer, glPopClientAttrib, > glPixelStore, glPushClientAttrib, glReadPixels, glRenderMode, > glSelectBuffer, glTexCoordPointer, glVertexPointer, and all of the > glGet commands. Those, in a nutshell, are the "nolist" functions. The "nolist" specifier is checked in the Python scripts that do automatic code generation, for example the "dlm" display list manager (which can track display lists itself, and has to know which functions are allowed to go into display lists) and the "tilesort" SPU. The "checklist" specifier is related; it is used to flag commands that can either act as queries (which do not go into display lists) or rendering commands (which do), depending on the value of their parameters; think of glTexImage2D, which can be used with GL_PROXY_TEXTURE_2D to check whether the implementation can store a given texture, or with GL_TEXTURE_2D to actually affect rendering. There are two levels of packing, one highly optimized path (where each command is packed as a single byte) and one "extended" path (where each command is packed as a single-byte CR_UNPACK_EXTEND opcode, with a four-byte "extended opcode" added to the start of the data stream). Since only 254 optimized opcodes are available, some care in their choice is important; you want the opcodes that are used often, especially the ones with small data payloads anyway. The "pack" and "extpack" indicators in APIspec.txt are used to make it easy to change that choice. "pack" functions are compiled into the small opcodes, and "extpack" functions are relegated to the extended opcodes. In general, you shouldn't change the current choices. New opcodes should all be "extpack". > It seems to me that all functions need > to be packed at some point, why would you label a function "nopack" ? I confess to not knowing exactly what "nopack" means... I strongly suspect you'll never need to use it. ;-) Bob Ellison Tungsten Graphics, Inc. |
From: Brian P. <bri...@tu...> - 2008-01-15 18:30:16
|
Chris Burns wrote: > Chromium folks, > > So I've decided to implement the extensions related to GLSL rather than > the 2.0 spec. I'm guessing it'll be similar to the way the > GL_ARB_vertex_program and GL_ARB_fragment_program extensions are > implemented. Yes, that's a good example to follow. > Given that, I noticed that Chromium keeps track of a lot of the state > related to the fragment_program and vertex_program extensions within the > state_tracker. Is it necessary that this approach be followed for the > GLSL shader extensions to get them working, or is this essentially there > for good performance (but not strictly necessary)? It's necessary for tilesort to work, for example. In other cases, like a sort-last config, you could probably get by without it. > Also, I'm not clear on what all of the "props" and "chromium" props > values in the APIspec.txt file really mean. In particular, i dont' > understand what "nolist" means and whether a given function should use > it, I believe nolist means the function should not get compiled into display lists. glGet* functions are examples. > and I'm not sure how to determine whether a given function should be > tagged "pack" or "extpack". It seems to me that all functions need to > be packed at some point, why would you label a function "nopack" ? Some functions, like glPixelStore are interpreted on the client-side only and aren't packed into the protocol stream. Though, I seem to recall we might be packing glPixelStore commands for some reason in Chromium. Other functions aren't packed but instead converted into other calls which are packed. For example, I think glTexEnvi is converted to glTexEnvf. I guess in general, look for other existing functions similar to the ones you have questions about. -Brian > > Chris~ > > > On Jan 14, 2008, at 3:16 PM, Brian Paul wrote: > >> Adding to the core is basically equivalent to adding extensions in >> this case. Both involve adding new entrypoints and the underlying code. >> >> -Brian >> >> Chris Burns wrote: >>> I've read the document about adding OpenGL extensions to Chromium. >>> I'm not sure what exactly the differences are in adding an extension >>> versus adding core routines, since there is no guide to extending >>> Chromium to new versions of OpenGL. >>> As it happens, my immediate need is for GLSL shader support, which is >>> available through an ARB extension (not currently implemented in >>> Chromium), as well as the 2.x core API. Do you know that it would be >>> simpler to simply add support for this extension rather than adding >>> the functionality as core routines? >>> Chris~ >>> On Jan 11, 2008, at 8:35 AM, Brian Paul wrote: >>>> Brian Paul wrote: >>>>> Chris Burns wrote: >>>>>> Hi, >>>>>> >>>>>> I am working with a PC linux cluster that's using DMX and Chromium >>>>>> 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem I'm >>>>>> having is that there seems to be an issue with OpenGL 2.0. >>>>>> Specifically, I get a NULL pointer back when I try to call >>>>>> glCreateShader with either GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. >>>>>> >>>>>> If I re-login to the machine without DMX and run only on the head >>>>>> node of the cluster, everything runs fine. Chromium doesn't seem to >>>>>> make much difference either way. >>>>>> >>>>>> Does anyone know if DMX is somehow not compatible with the latest >>>>>> OpenGL API routines, or could show me where I need to look to find >>>>>> out why I'm getting NULL? >>>>> >>>>> The problem is Chromium does not support OpenGL 2.x. >>>>> >>>>> It would be a fair-sized task (a couple weeks?) to implement but if >>>>> you're game, I could give some pointers. >>>> >>>> Several people have asked me for more details off-list. Let's keep the >>>> 2.0 discussion on the list. Maybe several people can cooperate on it. >>>> >>>> Here's my previous reply: >>>> >>>> >>>> The glapi_parser/APIspec.txt file defines all the GL functions. You'd >>>> begin by adding the GL 2.0 functions. Then, when you run 'make' >>>> quite a >>>> few python scripts will use the spec file to generate various .c files. >>>> There will be some failures where hand-coded functions will probably >>>> be needed. Hand-coded functions are usually listed in "special" files. >>>> >>>> I think there's a doc/ file that talks about how to add support for new >>>> GL extensions. That probably has some tips too. >>>> >>>> -Brian >>>> >>>> ------------------------------------------------------------------------- >>>> >>>> Check out the new SourceForge.net Marketplace. >>>> It's the best place to buy or sell services for >>>> just about anything Open Source. >>>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >>>> >>>> _______________________________________________ >>>> Chromium-dev mailing list >>>> Chr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/chromium-dev >> > > |
From: Chris B. <cb...@ta...> - 2008-01-15 18:20:41
|
Chromium folks, So I've decided to implement the extensions related to GLSL rather than the 2.0 spec. I'm guessing it'll be similar to the way the GL_ARB_vertex_program and GL_ARB_fragment_program extensions are implemented. Given that, I noticed that Chromium keeps track of a lot of the state related to the fragment_program and vertex_program extensions within the state_tracker. Is it necessary that this approach be followed for the GLSL shader extensions to get them working, or is this essentially there for good performance (but not strictly necessary)? Also, I'm not clear on what all of the "props" and "chromium" props values in the APIspec.txt file really mean. In particular, i dont' understand what "nolist" means and whether a given function should use it, and I'm not sure how to determine whether a given function should be tagged "pack" or "extpack". It seems to me that all functions need to be packed at some point, why would you label a function "nopack" ? Chris~ On Jan 14, 2008, at 3:16 PM, Brian Paul wrote: > Adding to the core is basically equivalent to adding extensions in > this case. Both involve adding new entrypoints and the underlying > code. > > -Brian > > Chris Burns wrote: >> I've read the document about adding OpenGL extensions to Chromium. >> I'm not sure what exactly the differences are in adding an >> extension versus adding core routines, since there is no guide to >> extending Chromium to new versions of OpenGL. >> As it happens, my immediate need is for GLSL shader support, which >> is available through an ARB extension (not currently implemented in >> Chromium), as well as the 2.x core API. Do you know that it would >> be simpler to simply add support for this extension rather than >> adding the functionality as core routines? >> Chris~ >> On Jan 11, 2008, at 8:35 AM, Brian Paul wrote: >>> Brian Paul wrote: >>>> Chris Burns wrote: >>>>> Hi, >>>>> >>>>> I am working with a PC linux cluster that's using DMX and Chromium >>>>> 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem >>>>> I'm >>>>> having is that there seems to be an issue with OpenGL 2.0. >>>>> Specifically, I get a NULL pointer back when I try to call >>>>> glCreateShader with either GL_VERTEX_SHADER or >>>>> GL_FRAGMENT_SHADER. >>>>> >>>>> If I re-login to the machine without DMX and run only on the head >>>>> node of the cluster, everything runs fine. Chromium doesn't >>>>> seem to >>>>> make much difference either way. >>>>> >>>>> Does anyone know if DMX is somehow not compatible with the latest >>>>> OpenGL API routines, or could show me where I need to look to find >>>>> out why I'm getting NULL? >>>> >>>> The problem is Chromium does not support OpenGL 2.x. >>>> >>>> It would be a fair-sized task (a couple weeks?) to implement but if >>>> you're game, I could give some pointers. >>> >>> Several people have asked me for more details off-list. Let's >>> keep the >>> 2.0 discussion on the list. Maybe several people can cooperate on >>> it. >>> >>> Here's my previous reply: >>> >>> >>> The glapi_parser/APIspec.txt file defines all the GL functions. >>> You'd >>> begin by adding the GL 2.0 functions. Then, when you run 'make' >>> quite a >>> few python scripts will use the spec file to generate various .c >>> files. >>> There will be some failures where hand-coded functions will probably >>> be needed. Hand-coded functions are usually listed in "special" >>> files. >>> >>> I think there's a doc/ file that talks about how to add support >>> for new >>> GL extensions. That probably has some tips too. >>> >>> -Brian >>> >>> ------------------------------------------------------------------------- >>> Check out the new SourceForge.net Marketplace. >>> It's the best place to buy or sell services for >>> just about anything Open Source. >>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >>> _______________________________________________ >>> Chromium-dev mailing list >>> Chr...@li... >>> https://lists.sourceforge.net/lists/listinfo/chromium-dev > |
From: Brian P. <bri...@tu...> - 2008-01-14 21:16:30
|
Adding to the core is basically equivalent to adding extensions in this case. Both involve adding new entrypoints and the underlying code. -Brian Chris Burns wrote: > I've read the document about adding OpenGL extensions to Chromium. I'm > not sure what exactly the differences are in adding an extension versus > adding core routines, since there is no guide to extending Chromium to > new versions of OpenGL. > > As it happens, my immediate need is for GLSL shader support, which is > available through an ARB extension (not currently implemented in > Chromium), as well as the 2.x core API. Do you know that it would be > simpler to simply add support for this extension rather than adding the > functionality as core routines? > > Chris~ > > On Jan 11, 2008, at 8:35 AM, Brian Paul wrote: > >> Brian Paul wrote: >>> Chris Burns wrote: >>>> Hi, >>>> >>>> I am working with a PC linux cluster that's using DMX and Chromium >>>> 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem I'm >>>> having is that there seems to be an issue with OpenGL 2.0. >>>> Specifically, I get a NULL pointer back when I try to call >>>> glCreateShader with either GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. >>>> >>>> If I re-login to the machine without DMX and run only on the head >>>> node of the cluster, everything runs fine. Chromium doesn't seem to >>>> make much difference either way. >>>> >>>> Does anyone know if DMX is somehow not compatible with the latest >>>> OpenGL API routines, or could show me where I need to look to find >>>> out why I'm getting NULL? >>> >>> The problem is Chromium does not support OpenGL 2.x. >>> >>> It would be a fair-sized task (a couple weeks?) to implement but if >>> you're game, I could give some pointers. >> >> Several people have asked me for more details off-list. Let's keep the >> 2.0 discussion on the list. Maybe several people can cooperate on it. >> >> Here's my previous reply: >> >> >> The glapi_parser/APIspec.txt file defines all the GL functions. You'd >> begin by adding the GL 2.0 functions. Then, when you run 'make' quite a >> few python scripts will use the spec file to generate various .c files. >> There will be some failures where hand-coded functions will probably >> be needed. Hand-coded functions are usually listed in "special" files. >> >> I think there's a doc/ file that talks about how to add support for new >> GL extensions. That probably has some tips too. >> >> -Brian >> >> ------------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> >> _______________________________________________ >> Chromium-dev mailing list >> Chr...@li... >> https://lists.sourceforge.net/lists/listinfo/chromium-dev > > |
From: Chris B. <cb...@ta...> - 2008-01-14 17:50:23
|
I've read the document about adding OpenGL extensions to Chromium. I'm not sure what exactly the differences are in adding an extension versus adding core routines, since there is no guide to extending Chromium to new versions of OpenGL. As it happens, my immediate need is for GLSL shader support, which is available through an ARB extension (not currently implemented in Chromium), as well as the 2.x core API. Do you know that it would be simpler to simply add support for this extension rather than adding the functionality as core routines? Chris~ On Jan 11, 2008, at 8:35 AM, Brian Paul wrote: > Brian Paul wrote: >> Chris Burns wrote: >>> Hi, >>> >>> I am working with a PC linux cluster that's using DMX and Chromium >>> 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem I'm >>> having is that there seems to be an issue with OpenGL 2.0. >>> Specifically, I get a NULL pointer back when I try to call >>> glCreateShader with either GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. >>> >>> If I re-login to the machine without DMX and run only on the head >>> node of the cluster, everything runs fine. Chromium doesn't seem to >>> make much difference either way. >>> >>> Does anyone know if DMX is somehow not compatible with the latest >>> OpenGL API routines, or could show me where I need to look to find >>> out why I'm getting NULL? >> >> The problem is Chromium does not support OpenGL 2.x. >> >> It would be a fair-sized task (a couple weeks?) to implement but if >> you're game, I could give some pointers. > > Several people have asked me for more details off-list. Let's keep > the > 2.0 discussion on the list. Maybe several people can cooperate on it. > > Here's my previous reply: > > > The glapi_parser/APIspec.txt file defines all the GL functions. You'd > begin by adding the GL 2.0 functions. Then, when you run 'make' > quite a > few python scripts will use the spec file to generate various .c > files. > There will be some failures where hand-coded functions will probably > be needed. Hand-coded functions are usually listed in "special" > files. > > I think there's a doc/ file that talks about how to add support for > new > GL extensions. That probably has some tips too. > > -Brian > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev |
From: Brian P. <bri...@tu...> - 2008-01-11 14:35:54
|
Brian Paul wrote: > Chris Burns wrote: >> Hi, >> >> I am working with a PC linux cluster that's using DMX and Chromium >> 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem I'm >> having is that there seems to be an issue with OpenGL 2.0. >> Specifically, I get a NULL pointer back when I try to call >> glCreateShader with either GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. >> >> If I re-login to the machine without DMX and run only on the head >> node of the cluster, everything runs fine. Chromium doesn't seem to >> make much difference either way. >> >> Does anyone know if DMX is somehow not compatible with the latest >> OpenGL API routines, or could show me where I need to look to find >> out why I'm getting NULL? > > The problem is Chromium does not support OpenGL 2.x. > > It would be a fair-sized task (a couple weeks?) to implement but if > you're game, I could give some pointers. Several people have asked me for more details off-list. Let's keep the 2.0 discussion on the list. Maybe several people can cooperate on it. Here's my previous reply: The glapi_parser/APIspec.txt file defines all the GL functions. You'd begin by adding the GL 2.0 functions. Then, when you run 'make' quite a few python scripts will use the spec file to generate various .c files. There will be some failures where hand-coded functions will probably be needed. Hand-coded functions are usually listed in "special" files. I think there's a doc/ file that talks about how to add support for new GL extensions. That probably has some tips too. -Brian |
From: Brian P. <bri...@tu...> - 2008-01-10 14:55:56
|
Chris Burns wrote: > Hi, > > I am working with a PC linux cluster that's using DMX and Chromium 1.9 > to run OpenGL apps on a 3x3 tiled wall display. The problem I'm having > is that there seems to be an issue with OpenGL 2.0. Specifically, I > get a NULL pointer back when I try to call glCreateShader with either > GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. > > If I re-login to the machine without DMX and run only on the head node > of the cluster, everything runs fine. Chromium doesn't seem to make > much difference either way. > > Does anyone know if DMX is somehow not compatible with the latest > OpenGL API routines, or could show me where I need to look to find out > why I'm getting NULL? The problem is Chromium does not support OpenGL 2.x. It would be a fair-sized task (a couple weeks?) to implement but if you're game, I could give some pointers. -Brian |
From: Chris B. <cb...@ta...> - 2008-01-10 01:14:42
|
Hi, I am working with a PC linux cluster that's using DMX and Chromium 1.9 to run OpenGL apps on a 3x3 tiled wall display. The problem I'm having is that there seems to be an issue with OpenGL 2.0. Specifically, I get a NULL pointer back when I try to call glCreateShader with either GL_VERTEX_SHADER or GL_FRAGMENT_SHADER. If I re-login to the machine without DMX and run only on the head node of the cluster, everything runs fine. Chromium doesn't seem to make much difference either way. Does anyone know if DMX is somehow not compatible with the latest OpenGL API routines, or could show me where I need to look to find out why I'm getting NULL? Chris~ |
From: Brian P. <bri...@tu...> - 2007-12-06 00:56:23
|
Jane Ren wrote: > Hi, > > When we use one of our software packages with Chromium, it prints out a > bunch of warnings for unimplemented tilesort functions PushName and > PopName. Is this a problem? > > I see that in Chromium, PushName and PopName are listed in the file > cr/spu/tilesort/tile_sort_unimplemented_special. I haven't been able to > find any documentation on this file. The tilesort SPU does not support feedback/selection modes. The Feedback SPU can do this though. Try inserting a Feedback SPU in front of your Tilesort SPU. -Brian |
From: Jane R. <j2...@uc...> - 2007-12-05 21:56:29
|
Hi, When we use one of our software packages with Chromium, it prints out a bunch of warnings for unimplemented tilesort functions PushName and PopName. Is this a problem? I see that in Chromium, PushName and PopName are listed in the file cr/spu/tilesort/tile_sort_unimplemented_special. I haven't been able to find any documentation on this file. Thanks. |
From: Olek S. <o.s...@ft...> - 2007-10-25 21:12:23
|
hey guys, can anyone try to answer some questions about chromium. we're looking for a vr-system that fits our requirements, which are...: opengl-compatibility -------------------- - are there any limitations concerning the use of opengl-extensions? - what facts should i be aware of, if i'm trying to use shaders (which shading languages are supported?) - relative coordinates per node? display-support --------------- - how can i configure the display-setup - is a full-screen(s)-framebuffer readback possible? - what about stencil-/accumulation buffer? data-import ----------- - is it possible to import 3d-data? (helper-classes) cluster support --------------- - one view per node or load-balancing? tracking support ---------------- - is it possible to use tracking devices like ARTrack? (- event-handling?) sound support ------------- - is there a sound module available (which supports openal)? - and if so, is it possible to have an extra server for the sound? it would be very very kind of you if you could spend some time to answer at least a few questions. thanks, o. schmidt |
From: jobieg <jo...@fa...> - 2007-09-17 08:35:23
|
Hello, I think you need to add the developer's tools to your cygwin installation. You can do this in the installation program by setting the appropriate packages to "install" (e.g. the make utility). It seems the install scripts are looking for the microsoft compiler (cl.exe) which you can get from the free visual studio express edition. regards Jo. nicola milano wrote: > > I would to install chromium cr-1.9 on wondows XP,i have installed > Cygwin,Python 2.5.1,win32py,but when i write ,on the Cygwin's shell, make > i > see in the shell:command not found.why??what is the problem??thank you > > _________________________________________________________________ > Se hai fatto un bel viaggio raccontalo sul nuovo Diari di viaggio > http://diaridiviaggio.it.msn.com/ > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Chromium-dev mailing list > Chr...@li... > https://lists.sourceforge.net/lists/listinfo/chromium-dev > > -- View this message in context: http://www.nabble.com/help-me%21%21%21-tf4428629.html#a12708595 Sent from the Chromium - Dev mailing list archive at Nabble.com. |
From: nicola m. <cra...@ho...> - 2007-09-12 11:26:06
|
I would to install chromium cr-1.9 on wondows XP,i have installed Cygwin,Python 2.5.1,win32py,but when i write ,on the Cygwin's shell, make i see in the shell:command not found.why??what is the problem??thank you _________________________________________________________________ Se hai fatto un bel viaggio raccontalo sul nuovo Diari di viaggio http://diaridiviaggio.it.msn.com/ |
From: Dan P. <ph...@cs...> - 2007-07-06 20:37:44
|
Has anybody written an SPU to profile the latency of commands as they go through the pipeline (e.g. time it takes for a GL command to get passed from application to HW)? If not, I'm interested in writing this to get my feet wet, so if there are any pointers, they'd be much appreciated! -dan |
From: Ken F. <k....@li...> - 2007-03-26 23:16:30
|
Hi everybody, I am trying to make a 3 projectors wall screen and I found, if I am not wrong, that the overlap_blending and overlap_levels parameter of the server are not good enough. They offer only one different value of intensity between two tiles, not a smooth and linear relative degradation. My idea is to add a smooth trasparent texture in the overlap region directly in the render SPU. First I added these lines in the function renderspu_SystemSwapBuffers( WindowInfo *w, GLint flags ) in renderspu_glx.c: render_spu.self.Color3f(1, 1, 1); render_spu.self.Begin(GL_LINE_LOOP); render_spu.self.Vertex2i(0, 0); render_spu.self.Vertex2i(200, 200); render_spu.self.Vertex2i(400, 0); render_spu.self.Vertex2i(1, 1); render_spu.self.End(); It works, and it's easy, via some costum parameter or the render_spu.window_title to switch between the displays. Ok with lines, but with texture, I was not able. After reading the "NeHe's OpenGL Tutorial Lesson 08" (http://nehe.gamedev.net) I have added: GLuint texture[3]; to the top of the file and 2 functions: renderspu_loadBMP and renderspu_loadGLTextures thas is: Bool renderspu_loadGLTextures(void) { GLboolean status; textureImage *texti; status = 0; texti = (textureImage *) malloc(sizeof(textureImage)); if (renderspu_loadBMP("glass.bmp", texti)) { status = 1; render_spu.self.GenTextures(3, &texture[0]); render_spu.self.BindTexture(GL_TEXTURE_2D, texture[0]); render_spu.self.TexImage2D(GL_TEXTURE_2D, 0, 3, texti->width, texti->height, 0, GL_RGB, GL_UNSIGNED_BYTE, texti->data); ........... } } I call the renderspu_loadGLTextures function to generete the texture in the set_borderless function in renderspu_config.c. When I start Chromium , it reports a segmentation fault error just before the call to the render_spu.self.GenTextures(3, &texture[0]) line. Using debug mode, the debugger can't go inside this function, as if it's empty and it reports immediately the crash. Hoping this issue is useful for many others Chromium users, I thank you everybody for the help, Mike |