Vlákno názorů k článku
Valve zpřístupnilo vrstvu pro překlad Direct3D do OpenGL pod svobodnou licencí od Lael Ophir - Umí to jen limited subset of Direct3D 9.0c....

Co se týče tisku, tak právě většinou se tiskne něco jiného, než co se kreslí na monitor. A hlavně jiným způsobem. Posílat tiskárně bitmapu je koncept hodný levných inkoustovek. Solidní tiskárny zvládají postscript, některé přímo PDF. Tyto formáty jsou podstatně úspornější na pásmo a přenášejí se do tiskárny výrazně rychleji, než velká bitmapa. Takže si nemyslím, že display server má něco společného s tiskem. Alespoň ne obecně a ne dnes - možná v časech dávno minulých...

Zrovna přesměrování zvuku občas používám. Je fajn mít zvuk na desktopu s připojenou reprosoustavou a obraz na tabletu v posteli z aplikace spuštěné z NTB na stole:-) Stejně tak je fajn mít možnost pustit si audio stream z jiného stroje na síti nebo naopak přesměrovat svůj audio stream na jinou stanici. A věřím tomu, že moje fantazije je v tomto směru hodně omezená. Jinak s tou aplikací pro připojení se zvukem máte pravdu - ještě jsem ji na Linuxu nepotkal. Ono prostě stačí připsat jeden parametr ssh a jeden další řádek to terminálu na hostovi, tak to asi nikdo nepovažoval za užitečné dávat do klikátka.

To, že RDP umí zpřístupnit vzdálene klíčenku, je rozhodně dobré. Ale proč zrovna USB klíčenku? Proč ne disketu? Nebo disk na firewire? Nebo optický disk? A jak to souvisí se zobrazováním? Přijde mi to prostě jako nekoncepční řešení. V Linuxu a nejen tam je na tunelování USB samostatná služba - tu si buďto pustím, když chci USB tunelovat a nebo nepustím, když nechci. Stejně tak pokud chci tunelovat nějaké další rozhraní. A zase mám svobodu v tom, že tunelování rozhraní není spjato se zobrazováním, takže může běžet z jiného stroje - třeba když chci flashku z NTB, zatímco na telefonu si zobrazuji okno aplikace.

Je to dany primarne tim, ze widle nepracujou s USB jako s diskem - proto trebas na widlich nemuzes na USBcku vytvorit vice oddilu ... holt nekdo u M$ myslel az vymyslel ... kdyby to totiz udelali tak, ze se to jako disk chovat bude, tak pak neni problem uplne stejne pripojit libovolnej disk.

Windows samozřejmě s USB klíčenkami pracují jako s diskem. Koncepčně ale mají nahrazovat diskety, takže Windows nabízí vytvoření jediné partition, a mountuje jen jednu partition.

Přes RDP lze připojit libovolný disk. Jenže je to pochopitelně potřeba pro každý disk potvrdit na klientovi. V případě USB klíčenek lze povolit jen USB port, a uživatel pak může kdykoliv připojit klíčenku - a nejen tu.

Má to jen jeden drobný problém. Tiskárna není displej. X11 samozřejmě tohle umělo (Xprint), ale nakonec to bylo odstraněno. Právě z toho důvodu, že tiskárna není displej, na tištěné stránky např. nepatří tlačítka, dekorace oken, menu a podobně. Pokud ale chcete zobrazit to, co se bude tisknout (WYSIWYG), tak to X11 umí pomocí Cairo.

Proč RDP neumí přesměrovat libovolné zařízení? Když si dovolím citovat: Celé je to důsledkem toho, že při návrhu RDP se na další zařízení vůbec nemyslelo.

Xprint uměl na tiskárně původně vytisknout jen dump bitmapy X11 serveru. Podpora dalších typů výstupu přišla velmi pozdě, a jako u všeho spojeného s X11 to bylo utrpení.

Tiskárna není display, ale chcete po ní přece kreslit totéž. Jak jsem psal, ve Windows si prostě vyžádáte device context tištěné stránky namísto okna, a kreslíte do něj. Nevidím důvod na stránku kreslit tlačítka a dekorace - ty přece většinou nekreslíte ani do okna WYSIWYG aplikace.

Při návrhu RDP se přemýšlelo nad tím, co uživatelé potřebují pro vzdálený přístup. Přesměrování síťového interface mezi těmi věcmi nebylo. Nicméně RDP je rozšiřitelné, takže máte volné ruce :)

Xprint uměl na tiskárně původně vytisknout jen dump bitmapy X11 serveru. Podpora dalších typů výstupu přišla velmi pozdě, a jako u všeho spojeného s X11 to bylo utrpení.

Protože je nesmysl tisknout pomocí příkazů pro kreslení oken. Obsah WYSIWYG oken klidně můžete vykreslit v PostScriptu a zobrazit je přes Cairo nebo (v době Xprintu) DPS.

Tiskárna není display, ale chcete po ní přece kreslit totéž
vs.
Nevidím důvod na stránku kreslit tlačítka a dekorace
?

Nejde o příkazy pro kreslení oken, ale o příkazy pro kreslení grafiky do těch oken. Vyberete si context (obsah okna, kontejner v okně, okno desktopu, dekorace okna), a zavoláte
e.Graphics.Draw­Bezier(blackPen, start, control1, control2, end);

Tyhle příkazy vám umožňují kreslit a psát text úplně stejně po tištěné stránce, jako po obrazovce. Liší se jen v tom, jestli je objekt Graphics obsah okna, tiskárna, plotr, nebo něco jiného.

Ve Windows navíc poskytují i drivery grafické karty a tiskárny stejné funkce. Vykreslení křivky (DrvFillPath) přece může mít stejný interface, ať jde o jakékoliv zařízení. Konkrétní implementace se samozřejmě liší podle zařízení: driver grafické karty může říct "neumím" a nechat si od GDI SW vyrastrovat bitmapu, driver plotteru to může přeložit na HPGL sekvenci, PS driver to převede na PS sekvenci atd.

BTW projekt Cairo se snaží přesně o tohle. Bohužel ale místo driverů s jednotným API musí používat tak odlišné back-endy jako X11, DirectFB, OpenGL, PostScript, SVG a kdo ví co ještě. Kde jsou Windows už dvacet let elegantní a praktické, Unixy to dnes zuřivě lepí sadou hacků vzešlou ze špatného návrhu.

Mno.. a co když budu chtít vykreslit NURBS křivku, nebo povrchovou reprezentaci objektu v podobě polygonů? To taky každý driver podporuje? A co když chci vykreslit CSG strom? A objekt reprezentovaný voxely? To driver každého zařízení všechno podporuje? Nebo se použije také knihovna - tedy stejný přístup, jako když se použije Cairo? A co když je to driver pro jehličkovou tiskárnu, co umí jen znakový režim? To prostě vykreslení selže, protože to driver neumí? Nebo drivery takových tiskáren mají generovat ASCII art? A co Brailův terminál? Přijde mi, že ta elegance pramení hlavně z omezených možností Windows - prostě v době, kdy ten návrh vznikal, se počítalo s monitorem a grafickou tiskárnou a ostatní věci se jaksi znásilňují na úrovni driverů, které pak mají velké a náročné procesy, každý to dělá po svém a každý jinak. Mě přijde elegantnější to vykreslit v knihovně nějakým způsobem pro různé "hloupé" backendy a těm to pak poslat. Výhodou takového řešení je i to, že oprava chybného vykreslování se vyřeší restartem aplikace s novou verzí knihovny a nemusí se reloadovat driver. Navíc jsou pak drivery malé a lépe udržovatelné. A rasterizaci počítá CPU tak i tak. Naopak tam, kde to jde, se použije chytřejší backend, jako OpenGL a pro rasterizaci se použije backend 1:1.

Jinak jako "bonus" jsou drivery na windows proprietární a zcela uzavřené a tedy oprava chyby v rasterizaci závisí na dobré vůli výrobce zařízení/driveru. Navíc kromě windows jsou i jiné OS s vlastním řešením - X server, Quartz, adnroidí display server, co nevím, jak se jmenuje;-) V důsledku toho pak mnohé aplikace rasterizují knihovnou - například ono Cairo, nebo QT raster engine a do elegantních driverů sypou už jen hotovou bitmapu v naději, že na ní už není moc co pokazit.

Na Androidu se to jmenuje Surface Flinger

Ten vás strach z nemožnosti si opravit zdroják je až komický. Kdy jste si naposledy opravoval chybu v OpenOffice nebo MySQL? Asi nikdy. Autor driveru vám samozřejmě může dát zdroják, pokud chce. Jenže on většinou nechce - opravy chyb řeší support. Uvědomte si také to, že na otevřeném Linuxu vám ty drivery i po více dvaceti letech fungují neskutečně mizerně, kdežto ve Windows prostě fungují. Na Linuxu se totiž z možnosti opravy často stává nutnost opravy (kterou stejně nakonec neuděláte, protože by to bylo velmi drahé).

Samozřejmě existuje více OS. Pokud máte tu smůlu, že musíte psát pro více platforem, budete zřejmě potřebovat nějaký wrapper. Například Cairo má jako jeden z back-endů GDI. Pochopitelně není potřeba rastrovat všechno v Cairu, i když například v případě použití OpenGL se asi spousta věcí bude řešit přesně takhle.

Ano, ve windows drivery prostě fungují - prostě nějak... ale že by fungovaly dobře, nebo dokonce bez problémů, tak to je spíše vroucné přání. Navíc na rozdíl od opensource driverů se ale reálně moc neudržují a problémy se řeší pořízením nového hardwaru s aktuálními drivery. Jestli vám tohle řešení přijde jako ideální, pak samozřejmě respektuji váš názor, na který máte nárok - ale souhlasit nemohu.

Ve Windows je situace s drivery uspokojivá. Jsou k dispozici drivery pro ohromnou spoustu zařízení a existuje funkční program testování a certifikace driverů. Na Linuxu je podpora HW výrazně menší, často nejsou vůbec testované na HW na kterém mají fungovat, nikdy nevíte jestli daný HW bude fakt fungovat, a hlavně často nefungují, nebo fungují napůl. Problémy jsou i s tak základním HW, jakým je grafická karta. O občasných příhodách s bricknutím HW raději ani nemluvit.

Souhlas, některé drivery pro Windows nejsou k dispozici pro novější verzi OS. Někdy se tomu dá pomoct. Jindy ne, a to zamrzí.

Tady si o tom můžete přečíst.
http://msdn.microsoft.com/en-us/Library/Windows/Hardware/ff570088(v=vs.85).aspx#E2

Typická ukázka vypadá tak, že driver prostě funguje. Samozřejmě se najdou výjimky. Když má zařízení procesor, zdá se, že nemůže fungovat bez chyby. Většina problémů s drivery je ovšem způsobená necertifikovanými drivery.

Nějak jsem si nevšiml, že by na tom otevřené ovladače byly lépe než ty uzavřené.

Ovladače ve Win8 jsou v pohodě. Stovky MB bloatware netvoří drivery, ale software instalovaný s nimi. Zkuste si instalační balík rozbalit, a uvidíte, že driver jako takový je malý. Instalace driveru ve Windows obecně nevyžaduje restart; samozřejmě ty podpůrné utility mohou naběhnout až po restartu prostředí.

Aplikace kreslí vždy stejně pomocí API, a o víc se nestará. Windows (typicky z GDI) pak pro většinu operací volají drivery. Drivery mají capabilities, kterými hlásí podporované operace. Například grafická karta asi bude umět nakreslit obdélník vyplněný barvou, PCL tiskárna nakreslit čáru a text, GDI nebo jehličková tiskárna (a všechna ostatní zařízení, snad vyjma HPGL plotterů) umístit bitmapu - těch operací je celá řada. Pokud driver nějakou věc neumí, tak jí nemá hlášenou jako podporovanou operaci, a Windows požadované volání API rozloží na volání, kterým driver rozumí. A mimochodem aplikace může sekvenci volání API serializovat do souboru typu EMF, a kdykoliv ten soubor nechat vyrastrovat na jiném stroji.

API pochopitelně nenabízí kreslení symbolu yin-yang, Utah teapot a dalších high level objektů. Pokud chcete vykreslit NURBS křivku, tak prostě použijete to, co vám API umožňuje. V tomto případě zřejmě Bezier curves a nějaké výplně.

Quartz na MacOS funguje dost podobně, akorát používá grafická primitiva postavená na PDF. To vychází z NextSTEPu, který měl DisplayPostscript. Ve Windows nebyl použit PS, protože byla potřeba licence od Adobe, a jeho rastrování bylo příliš pomalé.

Jak jsem už psal, Cairo se snaží o podobný přístup: aplikace kreslí voláním API po různých surfaces, a Cairo se stará o zbytek. Jenže to přišlo o 20 let pozdě, a navíc Cairo nekomunikuje s drivery, ale s X11, OpenGL, DirectFB, pluginem pro PDF, SVG apod. Jestli vám to přijde lepší, tak jste asi jediný.

Cairo je moderní systém. Dříve bylo na Linuxu DPS, což je vámi zmiňovaný Display PostScript.

Cairo komunikuje s drivery, například když vykresluje přes OpenGL.

Nikdy jsem neviděl použití Display PostScript na Linuxu. Údajně byla nějaká podpora v X.Org. Otázkou je na jaké úrovni, a jestli byl vůbec podporovaný tisk.

Super, Cairo si umí popovídat i s OpenGL knihovnou. Bohužel ty back-endy jsou každý pes jiná ves, což zvyšuje složitost kódu a přináší dodatečný overhead. Něco jako Cairo nebo DPS (bez toho nákladního vlaku historie z éry děrných štítků a textových terminálů) mělo být defaultním grafickým API před dvaceti lety, podobně jako GDI ve Windows.

BTW aby toho nebylo málo, situace se nezlepší a nevzniknou žádné Cairo-drivery. Přichází totiž Wayland a Mir, a Cairo je pokud jsem si všiml nepodporuje. Takže Cairo bude volat knihovnu libX11, ta bude volat xwayland nebo XMir, odtud na Wayland nebo Mir, a pak to snad už propadne na driver. Wow - to bude určitě rychlejší a spolehlivější, než to ošklivé X11 :/

DPS je PostScript, takže samozřejmě tisk podporovaný byl. Dodnes se vše na Linuxu tiskne primárně v PostScriptu. Přes CUPS. Úplně stejně jako na Macu.

Wayland i Mir jsou postavené na OpenGL, takže je celkem zřejmé, co použije Cairo.

DPS je API, které používá primitiva PostScriptu. Jinak na Macu se netiskne v PS. MacOS X používá pro kreslení po obrazovce i tisknuté stránce PDF primitiva, a drivery to pak převádějí například na PCL - je to něco úplně jiného, než na Linuxu.
http://en.wikipedia.org/wiki/Display_postscript#Modern_derivatives

Aha, tak ted uz chapu proc widle z 4MB PDF udelaji vice nez GB hruzu, kterou posilaji 1/2 hodiny na tiskarnu, aby ta nasledne prohlasila, ze tohle rozhodne tisknout nehodla ...

Velikost spool file záleží na více věcech:
- Samozřejmě velikost originálního souboru. Stostránkové PDF plné fotek asi bude mít velký spool file.
- Mizerně napsaný driver tiskárny.
- Samotné PDF. V PS generovaném některými šílenými aplikacemi jste mohl najít místo šedé výplně výplň z malých písmen "X", a podobné speciality, které se mohou reprezentovat dost obtížně. U PDF můžou nastat podobné problémy.
- Aplikace ze které se tiskne. Chce to například neprovádět resizing bitmap do cílového rozlišení, protože 100kB JPEG natažený přes celou stránku bude po převodu na 9600 dpi jistě zabírat daleko více místa.

Pokud tiskárna nesežere spool file, tak bych to viděl na driver. U HP jsem několikrát musel přejít na Basic Drivers (což je knihovna s popisem parametrů pro MS driver), protože ty Full Drivers byly nepoužitelné.

Myslim, ze si sam odpovidate - nemel by to resit, protoze je to DISPLAY server.

Na rozdil od ostatnich se tu nebudu zlobit, ze neco neni systemove, RDP nikdy k problemum systemove nepristupoval a jednotlive funkce byly postupne bastleny tak, jak to MS prislo, ze by je bylo hezke umet.

Univerzalni presmerovani USB zarizeni skrz RDP neni technicky mozne, protoze nelze obecne dodrzet casovani. Proste nemuzete mit ovladac na serveru a ovladat jim hw na klientovi. Tudiz je to cele nesmysl nazyvat presmerovanim USB zarizeni.

Dalsi vec je tisk. Kdyby to fungovalo tak uzasne, jak to popisujete, tak by server nepotreboval ovladace k tiskarne klienta. Dale by bylo uplne jedno, kde se tiskarna klienta nachazi, vykreslovani by totiz probihalo az na klientovi a tisk by byl z jeho pohledu tedy lokalni. Ale neni tomu tak. Nevytisknete nic na sitove tiskarne (LPR apod.), nevytisknete nic ani na tiskarne, kterou ma klient nasdilenou z jineho pocitace (pokud na ni server take nevidi).

Sdileni disku je pomerne prijemna vec, nicmene je to o dost pomalejsi, nez SMB, takze je to spise nouzovka. A urcite by to chtelo jeste trosku usili, protoze pouzivani subst pro mapovani pouze urcite podslozky je drbani se levou rukou za pravym uchem.

Vysmivat se X11 za to, ze neco neumi, nebo resi hure, nez RDP, je z meho pohledu hloupe. Souhlasim s tim, ze je RDP na sitovy pristup lepsi. Ale podivejte se o kolik je mladsi. Je odpovedi na X11 a kdyby se nepoucilo z jeho chyb, tak by to bylo ale sakra trapne, nemyslite? MS si za sebou ostatne taky vlaci peknych par kouli na noze, kuprikladu nesmyslne zamykani souboru a case-insensitivity. Trosku pokory prosim.

OK, takže nejlepší je kreslit po obrazovce jedním API a po tiskárně úplně jiným, protože... proč?

RDP je určené pro vzdálený přístup, takže MS přidává věci, které jsou důležité pro tento scénář.

http://blogs.msdn.com/b/rds/archive/2010/06/10/introducing-microsoft-remotefx-usb-redirection-part-1.aspx

Při tisku na klientskou tiskárnu přes RDP potřebuje server znát parametry tiskárny - podavače, velikosti papíru, netištitelné okraje atd. To že RDP fuguje pouze s lokálními tiskárnami klienta je by design.

Souhlas, sdílení disku je nouzovka.

X11 patří čestné místo v muzeu slepých cest osmdesátých let, nikoliv místo na desktopu.

V případě X11 připojím projektor a funguje. Dokonce i tam, kde Windows odmítaly vytvořit dva obrazy a trvaly na tom, že projektor je externí monitor a tak LDPS vypnuly.

Vice sesion najednou na desktopu rozhodne bez hackovani pripojeno byt nemuze ... takze nemel nesmysle. Instalaci ovladace brani predevsim to, ze widle ovladaci sdeli, ze takove zerizeni v systemu neexistuje. Stejne jako to zdeli libovolne aplikaci v ramci projektu boinc. K projektoru musim dojit osobne proto, ze v pripade pripojeni pres RDP jaksi aplikace nevidi zadnou jinou grafickou kartu a tudiz ani zadny vystup. Na linuxu spustim trebas pres ssh mplayer -display ... a pustim si vystup na libovolny z N monitoru.

RDP na serveru i desktopu je stejná technologie, na desktopu jen drobně ořezaná z licenčních důvodů. Nicméně vám nic nebrání použít Terminal Server, který sdílení session umí. Vyjma toho můžete také spustit prezentaci na jiném stroji vzdáleně.

Ještě jednou k instalaci driveru: jděte do Device Manageru, tam si najděte grafickou kartu, a nechte aktualizovat driver. Vychte ho vyhledat na webu, nebo si ho nainstalujte z lokálního stroje. Pokud to nepůjde, přijďte zpátky.

RDP vytváří virtuální driver pro každou session, a domlouvá s klientem, co vlastně umí. Pokud se aplikace zajímá, na jakém driveru jede, tak to samozřejmě není grafická karta serveru, ale ten virtuální driver. To může zabránit instalaci driver package přes setup, protože výrobce instalaci zastaví, když kartu nevidí. Přes Device Manager na tom ale nezáleží.

GPU akcelerace je ve Windows původně věc Direct3D shaderů. Samozřejmě pokud jedete na virtuálním driverů, který nemá 3D akceleraci, tak jí těžko použijete. Ale jak jsem psal, můžete použít RemoteFX vGPU. Pro výpočty na pozadí je navíc nesmysl používat Remote Desktop - napište si to jako Windows Service.

BTW většinu toho, co tu píšu, jsem vám psal už před pěti týdny.

Tak to jsou vývojáři asi magoři, protože naprostá většina PC her dál jede pod DirectX. Port na konzole řeší engine, nejspíš odlišnými code paths pro různá zařízení.

BTW PlayStation 4 nepoužívá OpenGL. Používá high level API GNMX, které je dost podobné DirectX, a low level API GNM, které na Windows nemá ekvivalent (možná AMD Mantle). Na shadery se používá PlayStation Shader Language.

PlayStation 3 používá OpenGL 2 ES. PlayStation 4 umí jak DirectX 11-like GNMX (pořád je ale potřeba celkem dost práce na portaci), tak OpenGL 4.

PlayStation 4 umí... OpenGL 4 - zdroj? Mě se to nepodařilo nikde dohledat. Wikipedie i Sony na GDC zmiňují jen GNM a GNMX. Ještě jsem dohledal poznámku, že PlayStation Shader Language je velmi podobný HLSL v DirectX 11.
http://en.wikipedia.org/wiki/PlayStation_4_system_software#Technology
http://www.eurogamer.net/articles/digitalfoundry-inside-playstation-4

Například zde.

PlayStation Shader Language je podobný HLSL z DirectX. Nebo nVidia Cg. Nebo GLSL z OpenGL. Protože to vše si je velmi podobné :-)

Aha. Článek psaný skoro rok před uvedením PS4, a nejspíš někým, kdo to API v životě neviděl, a GNM a GNMX kupodivu nezmiňuje. Naopak ti co portovali hru na PS4 píšou, že má dvě API pro grafiku, a to GNM a GNMX; o OpenGL ani slovo. Srovnejte relevanci vašeho a mého linku.
http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4

PlayStation 4 bylo oznámeno 20. února 2013, takže ten článek není předčasný. V té době spíš ještě nebylo vytvořeno GNMX pro snažší portaci Direct X her z Xboxu. Tady máte článek ze stejné doby, kde Sony zmiňuje OpenGL na PlayStationu, ale nezmiňuje GNM(X) (Zmiňuje i DirectX, ale to Sony asi těžko bude licencovat od Microsoftu.)

U hry napsané v Direct X je jistě velice bude zajímat podpora OpenGL :-)

Váš link uvádí, že PS4 má DirectX 11 a OpenGL 4.0. O tom dost pochybuji. Autor sám píše, že neví o čem píše. Pokud v diskusi padlo něco jako "GPU is DirectX 11 and OpenGL 4.0 capable", dost možná z toho vylezlo právě tohle.

Osobně za daleko relevantnější považuji to, co tvrdí lidé z Ubisoft Reflections, kteří mají přístup k dokumentaci a úspěšně portovali hru. Nějak se mi nezdá, že by přehlédli podporu OpenGL na PS4.

Každopádně pointa je ta, že vývojáři používají DirectX, a nejspíš ho budou používat dál. Pro portování na PS4 OpenGL nepotřebují, a podle všeho tam ani není k dispozic.

Znám jedno staré kočičí přísloví,které se sem teď docela hodí. CO TO SAKRA MELEŠ,TY VOŘECHU?

Naprostá většina Nových velkých her běží na DirectX. A změna se zatím rozhodně nechystá...

Vývojové prostředí se časem poněkud mění (jinak by to asi nebylo dobré), nicméně jsem s tím nikdy neměl problémy. Bohužel jsem se pořád nic konkrétního nedozvěděl.

On se měnil scope ridici promenne ve for cyklu? Pokud jsem si všimnul, tak se minimálně deset let nastavuje v compiler options. Nicméně vyjma "konfigurace vyberu projektu svazat se startup projektem" se to týká jazyka, nikoliv vlastního VS.

Já si připadám jako ve středověku vždycky když spustím Eclipse. Asi to bude o zvyku.

To se měsíc učíte, jako vypadá menu v nové verzi VS? :) Asi ne. Je to o změnách v implementaci jazyka. Pokud na problémy s přechodem na nový kompilátor narážíte často, tak je váš kód zřejmě v dost mizerné kvalitě.

Osobně píšu v .NETu, a IntelliSense si nemůžu vynachválit. V C++ bych doporučil se kouknout na troubleshooting section.
http://msdn.microsoft.com/en-us/library/vstudio/ms235519(v=vs.100).aspx

Goto definition mi funguje rychle a spolehlivě. Neznám rozsah vašeho projektu, velikost paměti počítače atd., ale typicky bývá problém způsobený nevytvořeným iPCH adresářem, případně vadnými PCH soubory. To by vám BTW řekli i na MS supportu :)

Na vašem místě bych si přečetl link níže, případně kontaktoval MS support.
http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx

Java i .NET jsou pro IntelliSense výrazně průhlednější, než C++. NetBeans jsem nepoužíval nikdy, těch pár řádků psaných v Javě mám v Eclipse.

Vždycky když musím dělat s VS v C# nebo C++, tak se snažím vzpomenout jestli vůbec někdy eclipse nebo netbeans napovídali tak blbě. Smutný je, že třeba v C++ napovídá lépe i codeblocks.

Ackoliv jsem toho nazoru, ze VS je naopak vynikajici produkt, ktery nechal konkurenci daleko za sebou, tak s intellisense ma Vas oponent pravdu. Skutecne by VS mohlo vyber promennych filtrovat ci radit dle ocekavaneho typu - a ano, rec je o C#. Ostatne je nekolik (pekne drahych) rozsireni VS, ktera toto a dalsi veci resi.

Jde zrejme o scope C# foreach promenne, ktery se zmenil mezi verzi 4 a 5. Ale to jste samozrejme s Vasimi hloubkovymi znalostmi vsech technologii (nejen MS) vedel a jen nas zkousite ;-)

kolega je určitě ťulpas co nepochopil ribbon atd. a vůbec ať je rád za MSVS, na linuxu by se musel učit reguláry, bash a gvim, čučet na to přes zastaralej X server a nakonec by mu to všechno postřílel OOM killer

Sám bych to nenapsal lépe. Nechcete tuhle práci místo mě? Můžeme se rozdělit o odměny :D

samohanu obvykle provádim v soukromí, ale díky za nabídku

You know that every time you speak against Microsoft... God kills a kitten? :)

to už by kočky byly dávno vyhynulej druh

kdyby si nikdo nestěžoval, tak by Lael nemusel dělat tu jeho "osvětu"

Co remcáte? Lael vám tady přijde kázat jedinou správnou víru a vy jste akorát nevděční. Půjdete do pekla, budete se smažit jako karbanátky.