>> >Please allow for *everything* in the comm layer (non-rectangular >> > views, >> >transparency, etc.). The API is limited, but that's no reason to >> > limit >> >the app_server. Also, I would reccomend having window borders drawn >> > as >> >a non-rectangular view by BWindow, and *not* by the app_server to >> > make >> >things more flexible. >> >-Nathan >> >> There is no requirement for that. That is definately an R2 thing. > >That's the idea. Since the internal messaging protocol isn't a >compatibility issue, why not put it in now? >-Nathan Two reasons: (1)performance and (2) it's a major pain to pass a BRegion to the server. I remember reading somewhere that using BRegions internally was something they considered, but it was too slow. There's a lot of overhead incurred when you use a BRegion because you can't assume that the thing is contiguous. There is suddenly a lot more clipping done when you use them, if for no other reason than each point must be clipped to the region before it is drawn. That's a serious performance hit, even with acceleration. BRegions store their rectangles in a pointer list (obviously), so each rectangle must be copied three times if you utilize a PortLink and twice if you do it the Hard Way (tm). Ouch. Transparent windows boils down to another BView flag, which shouldn't be too bad to the API - there are already 2 reserved flags in the header, one of which we can un-reserve. It'll also be a change in the server's redraw code. Ah, another thing for R2... --DarkWyrm