On Wed, 27 Apr 2005 10:49:30 +0100 Simon Poole <[EMAIL PROTECTED]> babbled: (B (B> > xferring lots of encoded video data) etc.? (B> (B> It's the nature of the servicing -- memory intensive image processing. (B (Bok - fair enough :) (B (B> > do. you can delete the client (ecore_con_client_del()) to instantly (B> > disconnect it (B> (B> Deleting the client isn't acceptable in this case -- it needs to be queued. (B (Bhmm - though it depends where you queue it (kernel or userspace) - but i from (Byour info later you don't have cntrol over the client... so... this makes sense (B:) (B (B> > - or you could simply queue it. it ends up just a (B> > client handle. it will read data sent and give it to you - but you (B> > can choose to just ignore it for a while, or whatever you please. (B> (B> I considered doing my own queuing, but presumably whilst I'm servicing a (B> client then I'll still be receiving data from the queued clients, using (B> up my precious RAM (embedded device, no swap!). I couldn't see a way of (B> "pausing" the reads on the queued clients until I'm ready for them. (B (Byeah. that's true. ecore_con was meant to be highly simplistic - taking away a (Blot of "hassle" for dealing with multiple clients and making it do a lot of (Bthe buffering and handling work for you, so in thew end u deal with only 3 (Bsimple things - a client got added, data from a client, and a client (Bdisconnected. but as you have found - it's missing controls for more (Bspecialised uses :) (B (B> Unfortunately the protocol we're using doesn't allow me to negotiate (B> with the client to ask it to hold back. It's a one-way push mechanism. (B (Bok - no control there :( (B (B> > leave) but if you are "too slow" to read the 200 move events in the (B> > middle - then you need to play catch up by skipping events). (B> (B> This is one of the things I really like about Ecore. It has really (B> strong architectural simplicity. It makes it incredibly quick and easy (B> to use. Well done! (B (Bthanks :) it's just a solution to having had to have done the same things again (Band again myself - so i throw it into a "kitchen sink" library that just (Bsimplifies it all so i only solve the problem once and get on with my app :) (Bit's not the only thing of its kind though - glib can do similar things. i (Bpersonally prefer my own methods - but it's much of a muchness - ecore does (Bthngs glib doesn't and vice-versa. the hugs advantage of ecore is i can get (Bchanges into it without a political battle :) (B (B> I'm working on the new electronic signage products for Lucid Signs (B> (http://www.lucidsigns.com/ (B> http://linuxdevices.com/articles/AT6529561810.html). They are (B> essentially LCD-based signs that think they are network printers. (B> (B> The print process uses our own binary protocol over TCP port 9100. (B> Clients (typically a Windows 2000/XP print driver) connect to this port (B> and send binary image data, which has to be decompressed, processed, (B> bit-packed, dithered (our framebuffer is limited to 16bpp) and (B> recompressed on the device as it comes in. This is necessary because (B> bit-packing and dithering on the fly at display-time is too slow on our (B> platform. (B> (B> Images vary in size, depending on screen resolution, and print jobs may (B> contain multiple pages. We have found it better to queue clients and (B> then process each job in turn. In fact, it would be extremely unusual (B> for more than one person to try to print to a single sign at the same (B> time anyway. (B> (B> If I reject a Windows print driver client because I'm busy, then Windows (B> will report an error and then retry, which has the right effect of (B> queuing it, but looks extremely flaky to an end user! (B> (B> This product is already on the market. The reason I'm moving our code (B> over to use Ecore is that we're doing a touchscreen interactive version (B> of the RoomSign product, and from what I've seen I believe that Evas is (B> going to be perfect for doing the UI. (B (Bwell from what you describe - evas will remove tonnes of your own code for the (Bgfx side - it does the dithering, decompression etc. for you - mind u - you end (Bup having to decode the imaging protocol into ARGB data for evas i guess. but (Byou already have that code floating about - the advantage is you can now (B"think" in ARGB and just object layers and high level and let the canvas do the (Bdirty work for you. evas is not the only thing of its kind around - but its (Bcompetition amazingly is fairly behind in terms of either speed, abilities or (Bquality - and almost always a combination of them (and almost always the (Bcompetition is a fraction of the speed in trying to do the same things) - so if (Byou looked at competing canvases it'd be interesting to know what you looked at (Band how it compares. i know i can improve speed more in evas - there's a few (Bmore tricks i can pull in the ram vs speed tradeoff wars. i can futz with ARGB (Bformatting and get speed for dest alpha targets - caching (B pre-scaled images, and maybe taking a new look at the scaling code - but i'm (Bnot sure i can get massive speedups (ie > 50%) without hardware acceleration :( (Bto date that's the worst thing entirely as any subsystem to do hw accel has its (Bown set of problems from stability to speed (its software fallbacks are so (Bawful its a decelerator by 20-200 times slower), or limited hw support etc. (B (B> Moving to Ecore has dramatically simplified some of our code, so we're (B> very grateful. When the EFL-based version gets released, I'll contact (B> LinuxDevices and get them to add a nice credit! (B (Booh - now that makes a lot of sense now - it helps to have a bigger picture :) (B (B-- (B------------- Codito, ergo sum - "I code, therefore I am" -------------- (BThe Rasterman (Carsten Haitzler) [EMAIL PROTECTED] $BMg9%B?(B [EMAIL PROTECTED] (BTokyo, Japan ($BEl5~(B $BF|K\(B) (B (B (B------------------------------------------------------- (BSF.Net email is sponsored by: Tell us your software development plans! (BTake this survey and enter to win a one-year sub to SourceForge.net (BPlus IDC's 2005 look-ahead and a copy of this survey (BClick here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix (B_______________________________________________ (Benlightenment-devel mailing list ([email protected] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
