[haiku-appserver] Re: current activity.

  • From: "Adi Oanca" <adioanca@xxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 12 Aug 2004 11:53:24 +0300

   >> DarkWyrm wrote:
   >> >> I'm still in doubt how regions are passed. Haven't looked at
   >> > > code. DW, can
   >> >> you enlighten me how big regions are sent to destination? (if
   >> > > this is possible?)
   >> >
   >> > Hmmm..... I don't think I ever figured that one out. I'd say that
   >> > probably the best way would be to attach the number of
   >> > clipping_rects
   >> > in the region and then iterate over the rectangles in the BRegion,
   >> > attaching them as clipping_rect objects via RectAtInt.
   >> OK OK, that is how it's done in present.
   >> What I was asking was: how do we send BIG regions across BPortLink?
   >That protocol-within-a-protocol thing is something I sort of have in
   >place already. Quite some time ago I wrote a class called AreaLink for
   >just such a case, but I know it still needs some serious reworking to
   >match the current API, but the basic idea was to create an area to dump
   >the object in it and tell the server about it, but I'm wondering about
   >a slightly different solution.
   >What if we have the app_server handle shared memory allocation in
   >instances aside from BBitmap? Every BApplication in R5 creates a couple
   >shared areas for working with the server. What if we set up a means for
   >each BApplication to have just one 4K area to start (which could change
   >size, of course) and when something really big needs to be sent over,
   >the client could request a certain size block of memory from the server
   >and memcpy the object into that allocated block of memory and then tell
   >the server to draw it or whatever. Feasible?
   Yes, because it's elegant and easy to work with.
   No, because, if a window crashes while it holds that area's lock, it would
   affect other windows.
   Yes, because that area won't be used that often.
   I really don't know...
   In order to support big objects we need a method like: uint32
   BPortLink::FreeSpace() const.
   >What is the current problem with sending really big ones over right
   AFAIK, they are too big and they are not send. An error is retuned.
   > Don't we reallocate the send and receive buffers in BPortLink when
   We do that? I though we were using a only-once allocated buffer.
   [ having a look at BPortLink... ]
   Ahhhh, I'm gonna kick some ass, and that's gonna be Phatz's!
   I thought we agreed on using a static buffer!!! If I send a BIG
   picture/region/polygon to server the buffer will get bigger and bigger and
   then drawing instructions instead of being sent to server, are cached
   slowing down server response. By NO means the buffer should be greater
   then 2K!!
   DW, do you agree with Phatz? Why?

http://www.videomax.ro/  -  Cautam cinefili pentru premiere!

Other related posts: