[SilverLight 2 / C#]

[RobLemmens]

Ik heb een hele tijd terug een vectorgebaseerde layouteditor gemaakt in c#. Nu wil ik voor een ander project deze hergebruiken voor op een webpagina. De class library van de layout editor was al enigzins voorbereid op een andere methode van tekenen naar het scherm dus hiero geen enkel probleem.

Probleem is Silverlight. System.Drawing word niet ondersteund en je kunt niet aan de pixel data van afbeeldingen komen. Aangezien het standaard image component enkel JPEG en PNG afbeeldingen ondersteund kun je ook niet zomaar een bitmap in een stream vasthouden en die steeds refreshen.

Ik ben hier omheen gegaan door de view van de edior op te delen in tiles. Elke tile is een PNG image stream zonder compressie en alle tekenoperaties tekenen rechtstreeks in de imagechuncks van de png. Vervolgens maak ik een grid met daarin image componenten. De images worden dan vanuit de png stream van de tile geladen. Gecombineerd met fatsoenlijke clipping werkt het beter dan ik initieel gedacht had maar kost het toch redelijk wat processor kracht. De bottleneck zit vooral in het toekennen van de gewijzigde stream aan het image component. Nu kan ik wel multithreaded gaan werken om de ervaring voor de gebruiker soepeler te maken maar mensen met een athlon 1000 ofzo zullen er ook dan geen prettige ervaring op nahouden. (op een @6600 draait het als een trein)

Men vraag is of iemand tips heeft in een andere richting om images te bewerken in silverlight. Of misschien wel een geheel andere aanpak.

[Niemand_Anders]

Image manipulatie is niet echt een eigenschap welke Microsoft ingedachten had voor Silverlight. Silverlight is simpel gezegd een uitgekleed WPF control met wat aanvullende .net libraries voor database, netwerk en file IO.

Silverlight is bewust erg licht gehouden zodat het ook goed op embedded (mobiele) apparaten kan werken.

Blijven twee mogelijkheden over namelijk als eerste een volwaardige WPF (desktop) applicatie of een XBAP applicatie. XBAP is een soort van hybrid client/server applicatie. XBAP (de GUI) draait in de browser, maar alle akties worden door de server uitgevoerd. Zowel in WPF of XBAP heb je het volledige .net framework tot je beschikking.

Ik weet niet hoe groot het canvas is waarop de 'bezoeker' kan tekenen, maar je zou vanuit silverlight via WFC of webservices de webserver kunnen benaderen welke de aktie uitvoert en vervolgens de gewijzigde image terug geeft.

Een en ander hangt vooraf van de requirements welke worden gesteld. Echter image bewerking is relatief zwaar en of je hebt de load op de client of je hebt de load op de server.

[RobLemmens]

De "canvas" is overal tussen 100x100 en 120k x 10k pixels (geen limiet, denk aan de zeilen van een vrachtwagen oplegger). De objecten zijn dan wel vector gebaseerd maar het is bv mogelijk om te gummen of tekenen op pixel niveau indien gewenst.

Het uiteindelijk gerenderde plaatje is na zoomen/scrollen iets van 70% van de schermresolutie, nog steeds een png van 4MB.. Die kan dan lossless gecomprimeerd worden (150ms/frame) maar dan nog gaat het vanaf de server updaten een probleem worden.

De requirements zijn materiaal voor the daily wtf: Iets van een simpele illustrator alike op een webpagina, moet werken op mac, linux en natuurlijk windows en moet met plezier te gebruiken zijn, dwz min 15 fps. Zou mooi zijn als eps/pdf ed ingelezen kunnen worden.... Ben er nu al 2 volle weken mee bezig en verwonderlijk genoeg is het tekenen het enige dat me in de weg zit.

Opzich is dat wat ik nu heb goeie maar ik kan moeilijk van een bezoeker verwachten dat ie minimaal een dikke P4 heeft, of tegenwoording wel?

[AtleX]

Zeker in een bedrijfsomgeving kan je wel verwachten dat er wel wat nieuwers staat dan je eerder genoemde Athlon 1000. En daarnaast is de klant niet de enige die eisen kan stellen aan een applicatie, jij kan ook stellen dat het programma pas goed draait op een (inmiddels goedkope) quadcore. Kijk maar naar spellen, die hebben ook systeemeisen. En de desktopvariant van je tool, Illustrator, ook.

[Sebazzz]

Niemand_Anders schreef op donderdag 23 oktober 2008 @ 14:29:
Blijven twee mogelijkheden over namelijk als eerste een volwaardige WPF (desktop) applicatie of een XBAP applicatie. XBAP is een soort van hybrid client/server applicatie. XBAP (de GUI) draait in de browser, maar alle akties worden door de server uitgevoerd. Zowel in WPF of XBAP heb je het volledige .net framework tot je beschikking.

XBAP is een desktop applicatie in je browser. Je hoeft echter niets te installeren enzo Acties (zoals FOpen) worden toch echt lokaal uitgevoerd. Daarnaast heb je ook het volledige framework nodig: Niet handig voor Mac of Linux users. XBAP support zit zviw nog niet in Mono.