原来翻译这么困难...胡乱译了几段,自己都没完全搞懂,以后继续吧.希望有能力的朋友帮助一下.
以下为翻译中的半成品,请帮助完成!谢谢!
-------------------------------------------------------------------------------------------------
二零零五年二月十六日,星期三
它来自从前,去拯救未来!
前言:为拟订下一代的 X 展示,这个blog入口对于眼睛糖果是实在太简略了.我致歉,但是我在家中,从我心爱的眼睛糖果那里分离出来,并且确定我必须在我被激发时写文章.作为强迫我自己手的方法,我现在制作了链接,它将包括将来的截图:-)
展示下一代的自由桌面
大约在过去的半年里,红帽子的桌面队伍已经让人们朝着展示制作促进图形的自由桌面的方向工作,但实际上做着谈论他们在大量公众/GNOME背景下做什么的蠢工作.他们已经作了联合实验(来自疯狂的 OpenGL 合成物/窗口管理器已向 xsnow 为了 X复合发生)并且开始认真工作着手没有把握的被禁止的基础下部组织工作(像在 Cairo 上制作 Win32 GTK 的工作以使 GTK 能够移植到 cairo 上来作为默认的支持者). 因为RHEL4 被剔除出门我们开始有能力去重新平衡在 GTK 和 X 上的日常工作在其他人之上给元老黑客们自由的双手.现在在红帽子的专职元老队伍是 Owen Taylor (GTK/Pango 的维护员), Søren Sandmann (X 的黑客),Diana Fong ( 视觉设计师), Kristian Høgsberg (X 的黑客)和 Carl Worth (Cairo 的维护员).
我真的很兴奋因为这些家伙的专业技术越过了宽阔的透视管道,从工具箱下至 X 服务器,它将给这努力的在这之上工作从全球透视的能力,而不是我们偶尔影响的最适宜的比特.我因为其它公司而双倍地兴奋(好,最起码Novell,但是很有希望地其它的会加入)也开始去为这个努力而投资!
我希望去拖曳 Owen 到...里I'm hoping to drag Owen into spinning this off into an umbrella effort (ala project utopia) to help maintain a coherent story/platform even as lots of people pour work into lots of different packages and distros. There are so many different ways to attack the X rendering issue that I'm a little worried about seeing a lot of fragmentation of effort and the result not being particularly coherent. I do hope people experiment with lots of different approaches, but I also really hope that in we can give developers a consistent platform for doing cool graphics on the free desktop. It would be a real shame to end up with the message in two years being "well, platform X has the feature you want, but you have to worry about also working with Y because X won't work well on distro Z". This sort of technology-choice morass can really dampen developers playing with this stuff and adding support all over GNOME, which is exactly the sort of quick-fiddling big-payoff stuff I think we'll see a lot of as soon as this stuff starts landing. In other words, lets push toward the point where people can feel confident and start hacking up cool things for this system inside GNOME.
What It Might Look Like
A really good system needs to have lots of pieces in place all hooked together....its not something that can be hacked apart and replaced by arbitrary random incompatible bits (though there are points of commonality, such as OpenGL or Render). For example the pieces in one imaginable architecture - by no means the decided-upon final one or anything - might look like:
* A sophisticated drawing layer (cairo using glitz/opengl or render as backends)
* Stock renderers built on top of that drawing layer (pdf/ps rendering backed by cairo - such as Alex Larsson's xpdf fork in evince, svg rendering backed by cairo, etc)
* A toolkit that agressively takes advantage of the features in the drawing layer, exposing them to applications and themes (gtk+)
* A window+compositing manager that can work closely with the toolkit but essentially takes the window contents as a static image in compositing (metacity with luminocity-like GL compositing manager features fused in to deal with window effects, synching up smooth resizing, live window thumbnailing, crazy pagers, etc)
* A hardware driver system to expose a low-level hardware accelerated rendering path to the drawing layer (opengl or render with hardware accel)
With that model we can implement things like:
* Toolkit themes that draw with layer blending effects, delightful bezier curves, and irritating alpha gradients
* Indiana Jones buttons that puff out smoothly animated clouds of smoke when you click on them
* Alpha transparency in applications whenever and wherever the urge strikes us
* Live window thumbnails
* Hardware accelerated PDF viewers
* Hundreds of spinning soft snowflakes floating over your screen.... without messing up nautilus
* A photograph of a field of long dry savanna grass as your desktop background... where the grass is gently swooshed around by a breeze created by moving your mouse across the background
* Windows that shrink scale and move all over the $$$$ing place with cool animations
* Synchronized smooth resizing so there's no disjunct between window borders moving and the contents redrawing (you should see the demos of this in luminocity... it really makes a difference in how real the interface feels, just as double-buffering did for stuff moving)
* A shared path between on-screen display and printing (using Cairo's PDF/PS backends)
* Vector icons with very occasional super subtle animations rendered in realtime...a tiny fly which buzzes around the trash every several minutes, etc... think mood animations as in Riven (which as a total random aside is still a shockingly beautiful and atmospheric game years after it came out, postage stamp sized multimedia videos notwithstanding)
* Workspace switching effects so lavish they make Keynote jealous
* Brush stroke / Sumi-e, tiger striped, and other dynamically rendered themes where every button, every line looks a little different (need to post shots / explanation of this stuff, but another day)
* Progress bars made with tendrils of curves that smoothly twist and squirm like a bucket of snakes as the bar grows
* Text transformed and twisted beyond recognition in a manner both unseemly and cruel
* A 10% opaque giant floating head of tigert overlayed above all the windows and the desktop.
* etc etc. In short: awesome.
And that's a conservative approach to this: each window essentially renders into a texture which are then combined in a separate rendering pass by the compositing manager. A lot of the work Diana does challenges our assumptions about what this rendering system should be able to do. For example, something as simple as a swoosh that cuts across both the window and the titlebar is currently very tricky. Diana's work has illustrated something that may be obvious, but seems to be forgotten in the excitement to build the One True Graphics Pipeline (this does not exist!): Its very important to figure out many of the things you want to do with the graphics system before you get in too deep and dirty, because there are a lot of directions we could go that call for rather different architectural choices. To give one example, if we decided we really cared about having lots of animations throughout GNOME (this isn't something we're pushing, but we talked about it) that would dictate a very different approach from a graphics system where we really really cared about printing. You can't always have your cake and eat it too... especially not when you consider implementation constraints.
Another example of how prioritizing "what do we want to improve with this" can change the direction: Since taking advantage of these new toys would require a new theme system, Havoc and I have been talking about how a very different theme / widget rendering system might work with this that allows for custom design of any window, widget, or anything in between. One of the things us designers have been experimenting with behind closed doors is what you can do with a window's design when its not drawn out of a bunch of stock widgets but you have a freer hand. (This does not mean visual inconsistency, just as a magazine can maintain a consistent look but still do a fresh layout for each page using a mix of stock and new elements.) The results can be really good. No matter how good the artist, you can only get so far designing a crude palette of some fixed number of widgets which are then used in preset. A good theme/widget rendering framework would help us negotiate this balance between re-using stock elements, and overriding the rendering of widgets at appropriate points to customize how a "Control Center Preference Page" is drawn or to simply shift the text in buttons over 10 pixels to the left. Figuring out how this stuff works, or if we just want to leave the theming issue alone (which would sort of be a shame given how much of the old flooring we're tearing up around it), may also have a significant impact on the final architecture.
A radical model (which also avoids multi-pass rendering without opening up security issues present in sharing direct access to existing graphic cards between processes) might involve a centrally rendered scene-graph where each client is given a subtree to add higher-level primitives. That could give us access to candy like pixel and vertex shaders (which we experimented with several months ago as part of rendering subtle but live backgrounds of grass fields, etc), which are attached to nodes on the render tree. Of course, there are many paths for leveraging shaders short of a full scene graph system. The scene graph model has a lot of significant concerns that are not as relevant to, say, 3D games where this model is common. Text rendering is one example.
Owen and company have slides from the X dev conf, but the punks did them as SVGs so unless you have their k-rad Cairo backed SVG slide presentation program, or if you're willing to view slides in Inkscape... they're not much good (though it is cool that you can find the slide you need using Nautilus thumbnails, but I digress) (hmmm, you can also open them in eog). Honestly, not the most inspiring OR detailed slides in the world either. I don't think they'd had much sleep when they wrote them up. *grin*
Anyway... I'm rambling. I've given a couple points too much depth, most points not enough depth, many points I've missed, and doubtless some I've gotten wrong, but I knew if I waited to write the perfect post on this there'd be only more backlog of material to share... so a braindump it was. :-) I guess in the end I'm pretty excited. It feels like we're running the last couple miles to get to the giant great-rendering payoff Keith Packard kicked off in the X world several years ago.
Code and stuff
* Cairo I think everyone knows about... writing for Cairo in Python or Mono is especially cool. Its really easy to get something that looks good going in short order. If you haven't played with it, you should!
* Luminocity is in GNOME cvs with the module name 'luminocity'
* Metacity compositing work is in 'metacity' with the branch 'spiffifity'
* GTK+ / Cairo integration.... gtk+ HEAD!
Apparently they also have a jhbuild setup that'll build all this stuff thats headed for CVS in fairly short order.
And for my last point...
Hula! |
IP卡
狗仔卡
发表于 2005-2-21 08:00:50
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主