光标所在位置对应窗口的查找理论

asmcos

问题:
鼠标在桌面移动的过程中,系统怎么快捷的判断鼠标当前落在那个窗口上?

实现办法一:
从顶层到下层窗口寻找,判断方法是:鼠标的X值是否在窗口的X1和X2之间.
并且鼠标的Y值是否在窗口的Y1,Y2之间.如果都是则鼠标在这个窗口内.
例如我们使用的窗口起始点是 300,200,终点 500x350.
鼠标是x,y
判断
if (300<x<500 && 200<y<350)
真
else
下一个窗口.
这样挨个窗口轮询.

此方法或许有些慢.

实现方法2:
在内存中存放同桌面分辨率等大小的像素对应窗口ID的映射表.
拿1024x768为例:
char map[1024*768];
对应的窗口像素位置填充好窗口的ID.这样通过ID关系查找到窗口.
例如我们使用的窗口起始点是 300,200,终点 500x350.窗口id = 15;
就要将同样大小的矩形区域填上15.
窗口在底下的最先填写,窗口在上面的最后填写.

此方法速度快但是消耗内存大.

实现方法3:
用1024x768为例:
每个窗口存放char width[1024],height[768].初始化为0.
例如我们使用的窗口起始点是 300,200,终点 500x350.
那么 将width[1024] 从300----500填充为1,其他为0,不变.
将height[768] 从 200---350填充为1,其他不变.
查找时从顶到下轮询窗口看width[x] &&height[y],同时成立.
挨个轮询.

此方法需要消耗部分内存,但速度很快.EGui使用了此方法.

asmcos

目前EGui的控件窗口是widget.
不是窗口管理器的管理范围.

但事件被确定到一个窗口后,另一个链表来判断控件位置.

每个应用维护自己的widget事件.

这种实现主要是实现widget查找.

这样避免一个窗口管理器程序.

一般模式: 硬件事件---->窗口管理器获取事件,查找对应窗口--->客户窗口.
窗口管理器是一个独立程序.一般需要通过网络或者其他方式和客户端联系.
很多widget都是窗口.归窗口管理器处理.

EGui没有窗口管理器程序.
硬件事件--->kernel里直接判断对应窗口----->客户窗口--->widget.
为了避免在kernel里有更多的工作量.我将widget部分放在每个应用里实现.

hiice

没有实际写过代码测试，纯拍脑袋：方法一似乎在查找的时候速度慢一些，而方法二和方法三在窗口移动时因为要维护映射表，似乎也会影响速度。而如果支持异形窗口的话，方法一和方法三似乎都不行，方法二应该可以。

asmcos

目前EGui不支持多边形窗口.
因为大家在日常操作中,窗口移动相对鼠标移动要少很多.所以EGui实现的效率肯定高一些.

但,这种效率的提高没有太多的实际意义.因为一般用户打开的窗口也就10-20个之间.不会太多.

swjbook

一个简单的窗口管理器似乎很必要，什么都要内核判断的话，不大符合细化的原则阿。内核什么都要做的话，太累了吧？
另外，如果没有异形窗口的话，还是采用第一种方法吧，这样更加直观阿。另外，窗口的重叠你怎么解决呢？如果另外两个方法，似乎比较难办。
窗口应该还有一个Z的坐标，标志了它的重叠的位置，于是靠上窗口Z越大。这样判断的时候，就知道，最上面的窗口要优先判断了。

asmcos

关于Z坐标,我目前是用链表实现的,在链表前面的是最上层窗口.挨个往下排.

目前不支持异型窗口.

关于窗口管理我已经交给另一个朋友实现.

asmcos

目前kernel层的窗口管理,只管窗口的大小,位置,和Z序.

一般系统只有20多个窗口,应该工作量不大.

嵌入式的应该更少.

wjfree

我感觉第二种似乎好一些，窗口的移动只要维护一个映射表就行了
第三种怎么会用内存比第二种小呢？它要为每一个窗口都建一个1024×768的数组啊，
而第二种只要一个就行了，而且速度不见得就比第二种快

是不是我还没有理解第三种方法？

asmcos

第3中，每个窗口只建立1024 + 768 。

wjfree

对，是我想错了

miniwin

我觉得查找鼠标位置的窗口按照每个窗口的可视区域做判断。一般来说20窗口也就100次左右，窗口的多少和判断的次数没有必然的关系，串口很多的情况下多数是不可见的窗口，但是这的等到完全实现窗口剪裁以后才能做

freeeman

第三种方法不会比第一种快多少，而且还浪费内存。